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LINUX KÜLÖNSZÁM 


Izgalmas vállalkozás eredményét tartja kezé- 
ben Kedves Olvasóm. Amint a címlap sugall- 
ja, megpróbáltunk egy olyan különszámmal 
kirukkolni, mely lehetővé teszi a pingvine- 
seknek, hogy benézzenek az ablakon. 
Tudom, hogy sok Linuxos eleve előítélettel tekint mindenre, ami 
ablakos, és nem hiszem, hogy ez az egyetlen különszám meg 
tudná téríteni az ily vakhitű egyedeket. A nyitott elméjű, kíván- 
csi pingvinek kukucskálására azonban feltétlenül számítunk! 





Mit lát az, aki benéz? 

Nem egy monolitikus, önmagának való operációs rendszert 
és alkalmazás-családfát fog látni, hanem szabványokon ala- 
puló, nyitott eszközöket. Régen elmúlt már az az idő, ami- 
kor a Microsoft helyes stratégiának tartotta a szabványok 
semmibe vételét. Most olyan időket élünk, amikor Billy 
(Gates) tucatjával hajítja ki termékeiből az oly sokat kriti- 
zált zárt, önmagának való megoldásokat. Szemétre kerül las- 
san a NetBIOS, a MAPI, az SMB, s helyüket fokozatosan át- 
veszi a natív TCP/IP, az SMTP és a HTTP. A folyamat valami- 
kor 1995-ben kezdődött, amikor Billy először szembesült az- 
zal, hogy ha a Microsoft nincs tekintettel a világra, akkor a 
világ sincs tekintettel őrá. Mindannyian tudjuk, hogy az 
Internet vonatára az utolsó pillanatban ugrottak fel, amikor 
a szerelvény már elhagyta a peront. A Windows 95 kibocsá- 
tásakor egy-két hónap leforgása alatt vett 180 fokos fordu- 
latot a cég, és állt a szabványok támogatása mellé. Ennek 
már hat éve. Ezért is megdöbbentő számunkra, hogy a régi, 
berögzült mondókákat egyesek akár fél évtizeddel azután is 
lelkesen, nyíltan hajtogatják, hogy azok létalapja megszűnt. 


Szabványok mindenütt 

A tech.net magazin egyik legnépszerűbb rovata a ,szabvá- 
nyok". Ebben hónapról hónapra egy-egy RFC-nek, Internetes 
szabványnak eredünk nyomába, s tárjuk olvasóink elé ezek 
lényegét. Így került sor a Microsoft Magyarország Szakmai 
Magazinjában a MIME (levelezés) , az MD5 (titkosítás, hash), 
a HTTP kiegészítése (a WebDAV), az XML (adatleírónyelv) , a 
SOAP (eljáráshívás) és sok más technológia ismertetésére. 
Még ott is szabványokkal találkozunk, ahol nem is gondol- 
nánk. Nem lennénk képesek az Internet adta lehetőségek ki- 
használására, ha operációs rendszereink hálózati felépítése 
nem lenne alapjaitól a tetejéig szabványos. 


És mi a helyzet a kernellel? 

Be kell vallanunk, hogy a kernel nem szabványos. De nem 
ám. Viszont tegye a szívére szárnyacskáját minden pingvin: 
a Linux kernele szabványos? Ugyan! Éppúgy az adott ope- 
rációs rendszer lelkivilágához faragott egyedi kód, mint a 
Windows esetében. Sőt, továbbmegyek: egy tőről fakadnak! 
Honnan is? 
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Pingvinek 


és 
ablakok 


Ez a Windows NT rövidítése. Játszunk el e három betűvel, 
matekozzunk rajtuk, hátha bűvös számmisztikánkkal elju- 
tunk valahova, ahol még senki sem járt. Csúsztassuk el 
mindhármat egyel visszafelé az ASCII kódtáblában. Mit ka- 
punk? Igen, az az! VMS! 


VMS 

A Windows NT operációs rendszer kernele szoros rokonságot 
mutat a Digital ősi , nagygépes" operációs rendszerével, a 
VMS-sel. A hasonlóság annyira szembetűnő, hogy egyszerűen 
nem lehet a véletlen műve. A virtuális memóriakezelés, a vég- 
rehajtási szálak prioritása, a preemptív multitaszk belső mű- 
ködése egyszerűen Digitalos és kész. (A kernel működéséről 
2001 augusztusi és szeptemberi számunkban jelent meg részle- 
tes elemzés.) A jelenség magyarázata egyszerű: miután a 
Digital ,nagygépes" üzletága végleg a PC háború áldozatává 
vált, Bill Gates, a hős, megmentette az ottani kiváló szakem- 
bereket a biztos éhenhalástól, és átvette a VMS fejlesztőcsa- 
patát a Microsofthoz. A VMS atyja, David Cutler lett 1992 tá- 
ján a születő új operációs rendszer, a Windows NT atyja! 


HAL 

A Windows platformfüggetlen, azaz nem csak Intel pro- 
cesszoron fut. Nem igazán tudtak elterjedni az Intel ellen- 
lábasai, a PowerPC konzorcium, az Alpha és a MIPS, de volt 
Windows változat ezekre a masinákra, mivel az operációs 
rendszer jelentős részét C nyelven írták, így könnyedén le- 
fordítható volt más gépi kódra is. Majdnem az egész 
oprendszer C-ben készült, annak a roppant hardverközeli 
kódnak a kivételével, mely például a processzorok védelmi . 
szintjeit, a hardver virtuális memóriakezelésének külön- 
bözőségeit kezeli le. A HAL nem más, mint a Hardware 
Abstraction Layer, azaz a ,hardvereldugási réteg". Ennek a 
résznek bizony gépi kódban kell készülnie, hogy gyorsabb 
legyen, mint a villám. Matekozzunk ezzel is! Csúsztassuk el 
ezt a három betűt is az ASCII kódtáblában, ezúttal felfelé. 
Na mi jön ki? Az bizony! 


IBM 

International Business Machines. A Microsoft a kilencvenes 
évek elején az IBM-mel karöltve reszelgette az 05/2-t. Akko- 
riban Billy azt hangoztatta, hogy a jövő operációs rendszere 
egyértelműen az 05/2. Majd összerúgták a port, és Billy kü- 
lönvált. A kész kódot azonban mindkét fél magáénak tekin- 
tette, és magával is vitte. Így került a Windows NT-be jó cso- 
mó IBM megoldás... 


Fóti Marcell 


tech.net! 


Hálózati 


terheléselosztás 


A Network Load Balancing (továbbiakban NLBS) a Windows 
2000 Advanced Server és a Windows 2000 Datacenter Server 
operációs rendszerek beépített szolgáltatása. Az NLBS na- 
gyobb rendelkezésreállást és stabilitást biztosít az Internet- 
kiszolgáló alkalmazások (például web- vagy FTP, és más, nagy 
fontosságú kiszolgálók) számára. A Windows 2000-t futtató 
számítógép önállóan a nagy rendelkezésreállási elvárásoknak 
csak korlátozottan felel meg, de az NLBS segítségével fürtbe 
rendezett Windows 2000 Advanced Server-ek kielégítik a nagy 
fontosságú és -rendelkezésreállású rendszerekkel szemben tá- 
masztott biztonsági és teljesítmény-elvárásokat. 

A szükséges kiszolgálóalkalmazások (web-, FTP-, telnet-, 
vagy levelezőkiszolgálók) a fürt minden tagkiszolgálóján 
futhatnak. A szolgáltatások egy része (például a webkiszol- 
gáló) az összes tagkiszolgálón egyidejűleg működik, az 
NLBS pedig a beérkező hálózati terhelést elosztja a tagok 
között, míg más szolgáltatásokat (például a levelezést) egy- 
idejűleg csak a fürt egy tagkiszolgálója látja el. Minden 
esetben az NLBS feladata, hogy hiba esetén a kiesett ki- 
szolgáló forgalmát egy másik, működő taghoz irányítsa át. 


Az NLBS működéséhez szükséges konfiguráció 

A Windows 2000 NLBS szolgáltatása hálózati meghajtóként 
működik, méghozzá olyan alacsony szinten, hogy a TCP/IP 
hálózati összetevők az NLBS jelenlétét nem is észlelik. 

A legjobb teljesítmény elérése érdekében az NLBS általában szá- 
mítógépenként két hálózati csatolót használ: az egyik csatoló 
feladata az ügyfelek kiszolgálása (mint rendesen) , a másik pedig 
az NLBS fürt ,adminisztratív" hálózati forgalmát kezeli. Termé- 
szetesen nincs akadálya annak sem, hogy minden forgalom gé- 
penként egyetlen hálózati csatolón keresztül bonyolódjon. 


Az NLBS fürtalkalmazások adatbáziselérése 

Sok kiszolgálóalkalmazás működése közben adatbázisban dol- 
gozik. Ha egy fürtben több ilyen alkalmazás működik egyidejű- 
leg, akkor különös gondot kell fordítani az adatbázisműveletek 
szinkronizálására. Egyszerűbb esetben minden tagkiszolgáló 
dolgozhat a saját, offline adatbázismásolatán, majd szükség 
esetén a változásokat frissítik (migrálják) egymás között, vagy 
a központi, , valódi" adatbázisban. Máskor egyidejűleg, hálóza- 
ton keresztül érik el az adatbáziskiszolgálót, de előfordulhat a 
fenti két eset kombinációja is. Például: a weblapok forrásállo- 
mányait nyugodtan felmásolhatjuk az összes tagkiszolgálóra, 
így rövidebb válaszidőt és nagyobb hibatűrést kapunk. A 
weblapokon keresztül érkezett adatbáziselérést igénylő műve- 
leteket ugyanakkor kezelheti különálló, megbízható adatbázis- 
kiszolgáló, amely egyszerre az összes tagkiszolgálót ellátja. 

A fontos vállalati alkalmazások a hibatűrő szolgáltatás bizto- 
sítása érdekében nagy rendelkezésreállású adatbáziskonfigurá- 
ciót igényelnek. Ilyenkor maga az adatbáziskiszolgáló is fürt- 
be rendezett számítógépeken fut, így biztosítja a nagy ren- 
delkezésreállást és a méretezhetőséget. Ilyen adatbáziskiszol- 
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gáló lehet például a Cluster szolgáltatás segítségével megvaló- 
sított kétpontos fürtre telepített Microsoft SOL Server. A Cluster 
szolgáltatás biztosítja, hogy ha a két csomópont közül az 
egyik kiesik (a csomópontot megvalósító számítógép meghibá- 
sodik), a másik csomópont átveszi a hibás egység feladatait. 
Teheti mindezt azért, mert a fürt két csomópontja közös me- 
revlemez-alrendszert használ. Az SOL Server ügyfelei pedig az 
átállásból csaknem semmit sem vesznek észre. 

Fontos, hogy a két fürtözési módszert megkülönböztessük 
egymástól. Az első, az NLBS fürt feladata elsősorban a beér- 
kező TCP/IP hálózati forgalom elosztása a rendelkezésre álló 
tagkiszolgálók között. Ezek a független tagkiszolgálók egy 
NLBS fürtöt képeznek. A második módszer a Cluster szolgál- 
tatás segítségével megvalósított fürt, amelyet két vagy több, 
fizikailag szorosan összekapcsolt, közös lemez-alrendszert 
használó számítógép valósít meg. A Cluster szolgáltatás se- 
gítségével leggyakrabban nagy rendelkezésreállású adatbá- 
ziskiszolgálókat építenek (amit azután természetesen akár 
NLBS fürtök háttérkiszolgálójaként is lehet használni). A két 
fürttípus együttes használatával teljeskörű, hibatűrő és nagy 
rendelkezésreállású fürtkörnyezetet teremthetünk. 


A hálózati terheléselosztás működése 

A hálózati terheléselosztás segítségével megbízható és mé- 
retezhető hálózati kiszolgálót hozhatunk létre két vagy 
több tagkiszolgáló számítógép fürtbe rendezésével. Az in- 
ternetes ügyfelek a fürtöt a fürt saját IP címén (címein) ke- 
resztül érik el. Az ügyfelek számára a fürthöz való csatlako- 
zás ugyanolyan, mintha közvetlenül a fürt egy tagkiszolgá- 
lójához kapcsolódtak volna; a kiszolgálón futó alkalmazá- 
sok sem észlelik, hogy egy fürtbe rendezett számítógépen 
futnak. (A Cluster fürt előnyeit csak speciális, erre tervezett 
alkalmazások képesek kihasználni.) Az NLBS fürt azonban 
mégsem ugyanolyan, mintha több különálló számítógépen 
futtatnánk az alkalmazásokat, hiszen a tagkiszolgáló hibá- 
ja esetén a szolgáltatás nem szakad meg, csak a bejövő há- 
lózati kapcsolatok átkerülnek a fürt még működő tagkiszol- 
gálóihoz. A fürt ezenkívül - a terheléselosztással működő 
portokon - nagyobb hálózati terhelést képes elviselni, mi- 
közben gyorsabb válaszidőt biztosít az ügyfelek számára. 
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Ha egy NLBS fürt tagkiszolgálója meghibásodik, a Network 
Load Balancing a beérkező hálózati forgalmat automatikusan 
a még működő tagkiszolgálók között osztja el. A leálló tag- 
kiszolgálóval létesített hálózati kapcsolatok elvesznek, de a 
szolgáltatás a fürtben továbbra is elérhető marad. A legtöbb 
esetben (például webkiszolgálók esetén) az ügyfélszoftver au- 
tomatikusan újra megpróbálkozik a megszakadt kapcsolatok 
felépítésével (tudtán kívül, de ezúttal már egy másik, még 
működő tagkiszolgálóval), az ügyfél pedig ebből mindössze 
csak a néhány másodperces várakozást veszi észre. 

Az NLBS a fürt egy vagy több saját IP címére érkező háló- 
zati forgalmat elosztja a rendelkezésre álló tagkiszolgálók 
között. A tagkiszolgálók egyidejűleg válaszolnak a különbö- 
ző ügyfelek kéréseire, akár egy ügyfél több kérésére is. Pél- 
dául: az ügyfél által megtekintett weboldal forráskódja a 
fürt egyik, míg az oldalon található képek a fürt egy másik 
tagkiszolgálójáról érkezik. Ez meggyorsítja a kiszolgálómű- 
veleteket és csökkenti a válaszidőt. 

Az NLBS fürt minden - közös alhálózaton található - tagki- 
szolgálója észleli a teljes bejövő hálózati forgalmat. A tagki- 
szolgálókon található NLBS eszközmeghajtó szűrőként műkö- 
dik a fürtre csatlakozó hálózati kártya és a számítógép 
TCP/IP komponensei között: a bejövő forgalom egy részét to- 
vábbengedi, más részét elnyeli (a TCP/IP nem is tud róla, 
hogy fürtben működik - hiszen hozzá már csak az a hálóza- 
ti forgalom jut el, amit az NLBS eszközmeghajtó jónak lát). 
A Network Load Balancing teljesen elosztott algoritmus se- 
gítségével az ügyfél IP címe, a port és egyéb információk 
alapján rendeli a beérkező kéréseket a tagkiszolgálókhoz. A 
beérkező csomagokat minden tagkiszolgáló megkapja és ki- 
elemzi, majd az algoritmus segítségével eldönti, melyik tag- 
kiszolgáló dolgozza fel a kérést. Ez a hozzárendelés egészen 
addig érvényben marad, míg a fürtben található tagkiszolgá- 
lók száma meg nem változik. Az NLBS szűrőalgoritmus sokkal 
hatékonyabb és nagyobb sávszélesség kiszolgálására képes, 
mint a központosított terheléselosztó megoldások, amelyek- 
ben a központi egység a hálózati csomagokat módosítja, 
majd továbbküldi a megfelelő tagkiszolgálóhoz. Az NLBS a 
tagkiszolgálókon fut, így működése nem korlátozódik adott 
processzortípusokra vagy hálózati megoldásokra. 


A hálózati forgalom elosztása 

Az NLBS a következő módon osztja el a beérkező Transmis- 
sion Control Protocol (TCP) és User Datagram Protocol 
(UDB) csomagokat a tagkiszolgálók között: a fürt saját IP 
címére érkező csomagokat a fürt minden tagkiszolgálója 
megkapja, majd az NLBS szűrők a csomagokban használt 
TCP és UDP portok alapján megszűrik ezt a forgalmat, mie- 
lőtt azok még a TCP/IP meghajtót elérnék. 

Az NLBS csak a TCP és UDP csomagokat dolgozza fel, nem szű- 
ri a beérkező Internet Control Message Protocol (ICMP), Inter- 
net Group Membership Protocol (IGMP), az IP- és hálózati cí- 
mek (MAC address) összerendelésére használt Address Resolu- 
tion Protocol (ARP) és más IP protokollokat sem. Minden ilyen 
forgalom akadály nélkül továbbítódik a tagkiszolgálók TCP/IP 
meghajtói felé. A TCP/IP felépítéséből következik, hogy nem 
okoz gondot a fürt IP címéről, több tagkiszolgálótól egyidejű- 
leg érkező többszörös válasz, bár ez a pont-pont alapú TCP/IP 
alkalmazások (például a ping) esetén probléma lehet. Ilyen- 
kor a tagkiszolgálók saját, közvetlen IP-címét kell használni. 
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HÁLÓZATI TERHELÉSELOSZTÁS 
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Custer Parameters ) Host Parameters. Port Rutez ] 
oten FF] o FESZ] 
Protocols CIC CUDP G Both 


Alfirly 6 tor 
€C Migiple hosts Load weight 










6 Single host Hi 


Add § há ére 


€C Disabled 
Stat — End — Protocol Mode — Piiodty Load Affiníty 
0 405 Both M E S 








a A hálózati terheléselosztás szabályainak beállítása 


Konvergencia 

Az NLBS fürt tagkiszolgálói szabályos időközönként broad- 
cast vagy multicast üzenetekkel hangolják össze a működé- 
süket, és felügyelik a fürt működését. Amikor a fürt állapo- 
ta megváltozik (ez történhet egy tagkiszolgáló leállásával, 
kilépésével vagy éppen megjelenésével), a fürtben elindul 
egy folyamat, melyben a tagkiszolgálók feltérképezik a fürt 
új állapotát, és alap értelmezett tagot választanak (ez a 
legkisebb prioritású tagkiszolgáló lesz). Ezt a folyamatot ne- 
vezzük konvergenciának. Miután ez megtörtént, a Windows 
2000 eseménynaplójában megjelennek a konvergencia be- 
fejezésére utaló bejegyzések. 

A konvergencia alatt a kiesett tag kivételével minden kiszol- 
gáló folytatja a működést, a változás a még működő tagok- 
kal létesített hálózati kapcsolatokat nem érinti. A konver- 
gencia befejeztével a kiesett tagkiszolgáló felé létesített há- 
lózati kapcsolatokat a még működő tagkiszolgálók átveszik. 
A hálózati forgalom úgy oszlik el a tagkiszolgálók között, 
hogy a hálózati terhelés egyenletes maradjon. Ha a fürtben 
új tagkiszolgáló jön létre, a konvergencia során belép a fürt- 
ben működő tagkiszolgálók sorába. A fürt bővítése nem za- 
varja a meglévő hálózati kapcsolatokat, sem az ügyfél-, sem 
a kiszolgálóalkalmazásokat. A több TCP kapcsolatot egyide- 
jűleg használó alkalmazásoknál azonban előfordulhat, hogy a 
konvergencia során - az affinitás ellenére - a két TCP kap- 
csolat különálló tagkiszolgálóra kerül. (Hiszen az affinitás 
csak a fürt felépítésének megváltozásáig érvényes.) 

A Network Load Balancing fürt tagkiszolgálója addig számít 
élőnek", míg az folyamatosan részt vesz a fürt tagkiszol- 
gálói között folyó kommunikációban. Ha a tagkiszolgálók 
adott ideig nem kapnak üzenetet egy másik tagkiszolgáló- 
tól, azt hibásnak veszik, és megkezdődik a konvergencia a 
kieső tagkiszolgáló terhelésének elosztására. Az üzenetek 
közötti időtartam és a konvergencia indításáig kimaradó 
üzenetek száma beállítható, az alapértelmezés 1000 ms 
(egy másodperc) , és 5 kihagyott üzenet. Mivel ezek a para- 
méterek ritkán változnak, a Network Load Balancing dialó- 
gusablakából nem módosíthatók: értékük szükség esetén a 
regisztrációs adatbázisban változtatható meg. 
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Kerberos 


A Kerberos Version 5 a Windows 2000 új hitelesítési proto- 
kollja. A protokoll önmaga egyáltalán nem új, immár több 
mint egy évtizednyi fejlesztés eredménye. Ebben a cikkben 
áttekintjük a Kerberos alapjait, használatának előnyeit, va- 
lamint azt, hogy miképp használja a Windows 2000 a Ker- 
berost mint hitelesítő protokollt. 


Hitelesítés a Windows 2000-ben 

A Windows 2000 rendszer erőforrásainak eléréséhez a fel- 

használónak hitelt érdemlően azonosítania kell önmagát. 

Ez az azonosítás általában a rendszerbe való belépéskor tör- 

ténik meg, ezután a felhasználó egy testre szabott , access 

token"-t kap, ami tartalmazza jogosultságait, csoporttagsá- 
gát, stb. A szolgáltatást nyújtó eszközök ezt az access to- 
kent ellenőrzik, majd ez alapján döntik el, hogy a felhasz- 
náló hozzáférhet-e egy erőforráshoz (megosztott fájlhoz, 
számítógéphez, stb.), vagy sem. A Windows 2000 hálózati 

(tehát nem telefonos) kapcsolaton keresztül felhasználóit 

két protokoll segítségével hitelesítheti: 

0 Kerberos Version 5 - A Windows 2000-t használó számí- 
tógépek között Windows 2000 tartományban alapértel- 
mezett hitelesítési protokoll. 

2 Windows NT LAN Manager (NTLM) - Az NTLM a Windows 
NT 4.0 alapértelmezett hitelesítési protokollja volt, a 
Windows 2000 elsősorban kompatibilitási okokból tartal- 
mazza. A különálló, nem tartományi tag (stand alone) 
Windows 2000 operációs rendszer - később látni fogjuk, 
hogy nyilvánvaló okokból - is NTLM hitelesítést használ. 

A Windows régebbi verziói (Windows 3.11, Windows 9x, Win- 

dows NT 4.0) az NTLM (illetve LanMan) hitelesítést fogják 

használni a Windows 2000-hez való csatlakozáskor. Ugyan- 
csak NTLM hitelesítést használ a Windows 2000 is, amikor 

Windows NT 4.0 számítógép vagy tartomány erőforrásaihoz 

szeretne hozzáférni. Ha azonban a Windows 2000-nek lehe- 

tősége van választani, választása minden lehetséges eset- 
ben a Kerberos Version 5 protokoll lesz. 


A Kerberos hitelesítés előnyei 

Vajon miért ragaszkodik a Windows 2000 ennyire a Kerberos 
protokollhoz? Az NTLM hitelesítésnek köztudottan több hát- 
ránya van: egyrészt, a kapcsolatfelvétel során a felhasználó 
jelszavából létrehozott , kivonat" (hash) többször megjelenik 
a hálózaton - ez bizonyítottan nem igazán biztonságos -, 
másrészt pedig a tartományok közötti hitelesítés folyamata 
kettőnél több tartomány esetén olyannyira elbonyolódik, 
hogy gyakorlatilag nem is lehetséges. Érthető tehát a szak- 
emberek és a Windows 2000 fejlesztőinek törekvése: nem 
elég, hogy egy új, biztonságosabb, hatékonyabb hitelesítési 
protokollra van szükség, de lehetővé kell tenni, hogy ez a 
protokoll teljes Windows 2000 környezetben 1009-ig kivált- 
hassa az NTLM hitelesítést. 

A Kerberos használata ezenkívül számos további előnnyel jár: 
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Gyorsabb kapcsolat - NTLM esetében a kiszolgáló (akihez az 
ügyfél fordult) a tartományvezérlő segítségével hitelesítette 
az ügyfelet (ez volt a ,pass through"). A Kerberos használa- 
tával a kiszolgáló önmaga hitelesítheti az ügyfelet, nincs 
szükség a tartományvezérlő közbenjárására, így csökken a 
hálózat terhelése. Ezen kívül - az NTLM-mel ellentétben - 
elég, ha az ügyfél egyszer beszerzi az adott kiszolgálóhoz 
szükséges hozzáférési lehetőséget, amit a kapcsolat további 
részében igény szerint akár többször is felhasználhat. 
Kölcsönös hitelesítés - Az NTLM-et alkalmazó rendszerek- 
ben a kiszolgáló azonosította az ügyfelet, az ügyfél (vagy 
akár egy másik kiszolgáló) azonban nem lehetett biztos ab- 
ban, hogy a kiszolgáló valóban az, akinek azt ő hiszi. A Ker- 
beros protokoll ilyen értelemben nem tesz különbséget: ki- 
szolgálónak számít mindenki, aki egy szolgáltatást mások 
által elérhetővé tesz, és ügyfél mindenki, aki egy ilyen szol- 
gáltatáshoz szeretne hozzáférni. A Kerberos hitelesítés 
mindkét résztvevője biztos lehet abban, hogy a kapcsolat 
másik végén az található, akinek az mondja magát. 
Meghatalmazásos hitelesítés - A Windows szolgáltatások, 
miközben egy ügyfél nevében tevékenykednek, egyfajta 
,Megszemélyesítést" alkalmaznak, így a szolgáltatásnak min- 
denhez pontosan annyi joga van, mint a hozzá kapcsolódó 
ügyfélnek. A helyi számítógépen belüli ilyen megszemélyesí- 
téseket mind az NTLM, mind a Kerberos lehetővé teszi. Csak 
a Kerberos képes viszont a ,megszemélyesítés" jellegű hite- 
lesítésre, amire a mai, háromrétegű alkalmazások esetén sok- 
szor szükség van - nevezetesen, hogy az alkalmazás középső 
rétegén található kiszolgáló az alsó réteg kiszolgálójával 
(például egy adatbáziskiszolgálóval) az ügyfél nevében és az 
ő jogaival felruházva tartja a kapcsolatot. Az NTLM nem tá- 
mogatja a hasonló megoldásokat. 

A tartományok közötti megbízotti kapcsolatok kezelése 
egyszerűbb - a kölcsönös hitelesítésnek köszönhető, hogy 
a Windows 2000 tartományok kapcsolatai alapértelmezés- 
ben kétirányúak és tranzitívak (tranzitív: ha A tartomány 
megbízotti viszonyban áll B tartománnyal, B pedig C-vel, ak- 
kor A automatikusan megbízotti viszonyba kerül C-vel is). 
A Windows 2000 tartományi fába rendezett tartományok 
kapcsolatai sokkal egyszerűbbek és átláthatók. A fa bármely 
tartománya, illetve tartományi erdő esetén az erdő bármely 
fájának bármely tartománya által kiadott hitelesítés az 
adott fában illetve erdőben érvényes. 

Együttműködés - A Windows 2000 Kerberos implementáció- 
ja az Internet Engineering Task Force (IETF) által ajánlott 
szabványokon alapul. A szabványos megvalósítás jó alapot 
teremt más, ugyancsak Kerberos Version 5 hitelesítési pro- 
tokollt használó rendszerekkel való együttműködésre. 
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BIZTONSÁG KERBEROS 

A Kerberos hitelesítési protokoll szabványai 

A Kerberos hitelesítési protokollt a Massachusetts Institute 
of Technology (MIT) szakemberei az úgynevezett , Project 
Athena" projekt keretében már több, mint tíz éve fejlesz- 
tik. A protokoll első nyilvános változata már a negyedik 
verzió volt. A v4 áttekintése és széles körű felhasználása 
során összegyűlt tapasztalatok alapján fejlesztették ki a je- 
lenlegi, ötödik verziót, amely jelenleg szabványjavaslatként 
található meg. A Windows 2000 Kerberos az RFC1510 imp- 
lementációja, a Kerberos segítségével átadott biztonsági 
erőforrásokhoz) pedig az RFC1964 Internet szabványjavasla- 
tot (GSS API) követik. 


A Kerberos bővítményei 

A Kerberos protokoll alapvetően szimmetrikus (közös kulcsú) 
titkosítási algoritmuson alapul, ezért a Windows 2000 az ere- 
deti Kerberos protokoll kibővített változatát használja. Termé- 
szetesen ez a bővítmény is egy IETF szabványtervezet megva- 
lósítása. Ez teszi lehetővé, hogy a Kerberos hitelesítési folya- 
mat korai szakaszában kihasználhassuk az aktív memóriakártya 
(smart card") és egyéb nyílt kulcsú infrastruktúrák előnyeit. 
A Kerberos és a nyílt kulcsú hitelesítés kapcsolatáról részlete- 
sebben a cikk második felében ejtünk szót. 


A protokoll áttekintése 

A Kerberos hitelesítő protokoll egy kommunikációs kapcsolat 
résztvevőinek kölcsönös azonosítását teszi lehetővé olyan kör- 
nyezetben, ahol az átvitt adat illetéktelenek által látható, mó- 
dosítható, egyszóval a biztonságos adatátvitel nem garantál- 
ható. Ez a környezet - természetesen - nagyon hasonlít nap- 
jaink Internetéhez, ahol az illetéktelen behatoló átveheti akár 
az ügyfél, akár a kiszolgáló szerepét, és így értékes informá- 
ciókhoz juthat. Feladatunk tehát egy olyan biztonságos kom- 
munikáció megvalósítása, amely az első kapcsolatfelvételtől 
kezdve kizárja az illetéktelen hozzáférést. 


Alapok - avagy legyen egy közös titkunk 

A Kerberos protokoll alapja a közös titkon alapuló hitelesítés. 
Az elv egyszerű: ha egy titkot csak két ember ismer, azok a kö- 
zös titok segítségével könnyedén azonosíthatják egymást. 
Vegyük példaként az angolszász világban oly népszerű párost, 
Alicet és Bobot. Tegyük fel, hogy Alice gyakran küld üzenete- 
ket Bobnak, Bob viszont szeretne biztos lenni abban, hogy az 
Alice-tól kapott leveleket valóban Alice írta. Elhatározzák, 
hogy együtt választanak egy jelszót, amit nem árulnak el ket- 
tőjükön kívül senkinek. Ha Alice üzenetén valahogy látszik, 
hogy Alice ismeri a közös titkot, Bob biztos lehet abban, hogy 
a levél valóban Alicetől származik. 

Adódik azonban egy probléma: honnan derül ki, hogy Alice va- 
lóban ismeri a titkot? Ha Alice beleírná azt az üzenetbe, akkor 
a nevető harmadik, a kis gonosz Carol elég, ha csak egy ilyen 
üzenetet elkap a hálózaton, a titok máris nem titok többé. Va- 
lami más megoldásra van szükség: anélkül kell jeleznünk a jel- 
szó ismeretét, hogy azt beleírnánk az üzenetbe. 

A Kerberos ezt közös kulcsú (más néven titkos kulcsú, vagy 
szimmetrikus) titkosítás segítségével oldja meg. A szimmet- 
rikus titkosítás lényege, hogy egy adott, közös kulcs segít- 
ségével titkosított üzenetet ugyanazzal a kulccsal tudunk 
csak megfejteni. A kommunikáció résztvevői pedig ezt a 
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kulcsot használják közös titokként. A titok ismerete egysze- 
rűen bizonyítható: egyik részről az üzenet titkosítása, má- 
sik részről a megfejtése a bizonyíték, hiszen a közös kulcs 
ismerete nélkül ezek egyike sem lehetséges. 


Hitelesítők (authenticators) 

Vegyünk egy egyszerű, titkos kulcson alapuló hitelesítési 

protokollt. A kapcsolatfelvétel elején valaki áll a virtuális 

ajtó előtt és bebocsátást kér. A belépéshez egy, a közös 
kulccsal titkosított adatcsomagot, úgynevezett hitelesítőt 
nyújt át. Az adatcsomag eredeti tartalmának minden eset- 
ben másnak kell lennie, különben a hálózaton elkapott hi- 
telesítőt később bárki illetéktelenül felhasználhatná. 

A kapu őre átveszi a hitelesítőt, majd az általa ismert tit- 

kos kulccsal megpróbálja megfejteni. Ha ez sikerült, az őr 

biztos lehet abban, hogy az ajtó előtt kívül olyasvalaki áll, 
aki ismeri a közös kulcsot. (Márpedig azt csak ketten isme- 
rik: az őr és a belépésre jogosult felhasználó.) 

Ha a hitelesítés kölcsönös, az őrnek is hitelesítenie kell önma- 

gát a felhasználó előtt. A teljes üzenetet nem küldheti vissza, 

hiszen azt a kulcs ismerete nélkül is bárki megtehetné. Inkább 

a megfejtett üzenet tartalmát valahogy megváltoztatja, majd a 

módosított adatcsomagot titkosítja, és hitelesítőként visszaad- 

ja az ajtó előtt álló idegennek. Az a saját kulcsával megfejti az 
üzenetet, ellenőrzi a tartalmát, és ha mindent rendben talált, 
biztos lehet abban, hogy az ajtónálló is rendelkezik a megfele- 
lő kulccsal: hiszen képes volt megfejteni az üzenetet, megvál- 

toztatni a tartalmát, majd titkosítva visszaküldeni azt. Ebben a 

pillanatban az őr és az idegen azonosították egymást. 

Lássuk ugyanezt kicsit részletesebben, Alice és Bob példá- 

ján. Alice a felhasználó, aki szeretne hozzáférni Bob egy 

szolgáltatásához. 

1. Alice egy üzenetet küld Bobnak, amely a saját nevéből, va- 
lamint egy, a közös kulccsal titkosított hitelesítőből áll. 
Ebben a példában a hitelesítő két adatmezőt tartalmaz: az 
egyik valami, ami azonosítja Alicet, mondjuk a neve; a 
másik pedig az Alice számítógépén mért pontos idő. 

2. Bob megkapja Alice üzenetét. Az üzenetből azonnal lát- 
szik, hogy olyasvalaki küldte, aki Alicenak mondja ma- 
gát. Bob a közös kulccsal megfejti a hitelesítőt, és így. 
hozzáfér Alice valódi nevéhez, valamint az Alice számí- 
tógépén mért időhöz. A protokoll működéséhez fontos, 
hogy Bob és Alice számítógépének órái szinkronizálva le- 
gyenek. Tegyük fel, hogy a két óra közötti eltérés soha 
nem nagyobb, mint öt perc. Bob tehát összehasonlítja a 
hitelesítőben kapott időt és a saját óráját. Ha az eltérés 
kevesebb, mint öt perc, Bob majdnem biztos lehet ab- 
ban, hogy az üzenetet Alice küldte. Azért csak majdnem, 
mert lehetséges, hogy Alice hitelesítőjét valaki a hálóza- 
ton elkapta, majd változatlanul, de öt percen belül újra- 
külte. Ez a megismételt hitelesítő a fentiek alapján még 
érvényesnek számítana. Bob ezt úgy kerülheti el, hogy 
megjegyzi az Alicetől utoljára megérkezett hitelesítő 
időpontját, és ha annál régebbi, vagy azzal megegyező 
időpontú hitelesítőt kap, legalábbis gyanakodni kezd. Ha 
azonban minden rendben van, immár biztos lehet abban, 
hogy az üzenet Alicetől érkezett. 

3. Most Bobon a sor: kiveszi az időpontot az Alicetől kapott 
hitelesítőből, azt a közös kulccsal újra titkosítja, majd 
visszaküldi Alicenek. 
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Figyeljük meg, hogy Bob nem a teljes hitelesítőt küldte 
vissza - hiszen arra bárki képes lenne -, hanem annak csak 
egy részét. Alice így biztos lehet abban, hogy Bob rendelkezik 
a közös kulcs egy példányával, hiszen képes volt megfejteni az 
üzenetet, módosítani a tartalmát, majd újra titkosítani azt. 
Alice megkapja Bob üzenetét, visszafejti a titkosított ada- 
tokat, majd a kapott időpontot összehasonlítja az ő általa 
küldött adattal. Ha a két időpont megegyezik, akkor Alice 
biztos lehet benne, hogy üzenetét Bob kapta meg, hiszen 
a közös kulcsot csak ők ketten ismerik. 


dat é 


Sziaitt Alice! "  KafAlice, idő) 





MISS. Bob 


Kafidő) 


5 Alice és Bob kölcsönös azonosítása (Kg a közös kulcs, 
Kagtfadat) a közös kulccsal titkosított adat jele ) 


Központosított kulcskezelés (Key Distribution) 

Ez azonban még korántsem jelent megoldást minden prob- 
lémára. Mindenekelőtt feltételezzük, hogy Alice és Bob 
előzőleg valamilyen biztonságos csatornán (mondjuk, fül- 
besúgással) megegyeztek a közös titokban. A számítógé- 
pek azonban viszonylag ritkán sugdosnak egymás fülébe, 
másrészt pedig ha nem kettő, hanem mondjuk nyolc egyed 
szeretne biztonságosan kommunikálni, bizony nagy lenne 
a sugdolózás. A súgás problémáját egyelőre hagyjuk el, te- 
gyük fel, hogy van mód arra, hogy biztonságosan megálla- 
podhassunk a közös kulcsban. A bábeli zűrzavart pedig úgy 
kerülhetjük el, ha kijelölünk egy központi egyedet, akinek 
mindenki megsúgja a saját kulcsát, és ha valaki kommuni- 
kálni szeretne, ugyancsak tőle kéri el a címzettnek szóló 
kulcsot. Az alábbi ábrán jól látszik, hogy mennyivel kisebb 
lesz a hangzavar. 




















o A központosított kulcskezelés lényegesen kevesebb 
kapcsolatot igényel 


Itt jön a képbe a görög mitológiából Kerberos (pontosabban 
Cerberus) , Hádes - az alvilág kapuját örző - háromfejű kutyá- 
ja. A modern Kerberos három feje a következő: az ügyfél, aki 
a szolgáltatást igénybe szeretné venni; a kiszolgáló, aki a 
szolgáltatást nyújtja; valamint a harmadik fél, aki segít ab- 
ban, hogy az ügyfél és a kiszolgáló végül egymásra találjon. 
Ez a harmadik fél, mint a fenti ábrán is látszik, a Key Distri- 
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bution Center (KDC). A KDC egy megbízható, biztonságos ki- 
szolgálón fut, ő kezeli a Kerberos tartomány (realm) bizton- 
sági adatbázisát. A Kerberos tartomány egyébként egyenran- 
gú a Windows 2000 tartománnyal (domain), tehát minden 
Windows 2000 tartományban található legalább egy, a helyi 
feladatokkal foglalkozó KDC. A KDC és az ügyfél egymás köz- 
ti kommunikációjuk során az ügyfél úgynevezett hosszú távú 
kulcsát (long-term key) használják, amit előzőleg általában a 
felhasználó jelszavából állítanak elő. A KDC természetesen a 
tartomány minden felhasználójának és számítógépének is- 
meri a hosszú távú kulcsát. 

Ha tehát egy ügyfél szeretné felvenni a kapcsolatot egy ki- 
szolgálóval, előbb szól a KDC-nek, aki az ügyfél és a kiszol- 
gáló jövőbeli kapcsolatára egy eldobható, úgynevezett rövid 
távú kulcs (session key) formájában áldását adja. Minden új 
ügyfél-kiszolgáló kapcsolathoz új rövid távú, más néven sza- 
kaszkulcs tartozik. A KDC ezt a rövid távú kulcsot az ügyfél 
hosszú távú kulcsával titkosítva elküldi az ügyfélnek; a ki- 
szolgáló hosszú távú kulcsával titkosítva elküldi a kiszolgá- 
lónak, azok megfejtik az üzenetet és az új, közös szakasz- 
kulcs segítségével máris indulhat a társalgás. 

Azaz csak indulhatna, de mi történik, ha a KDC csomagja a ki- 
szolgálóhoz valamilyen okból nem jut el? Az ügyfél hiába ko- 
pogtat a kiszolgálónál, süket fülekre talál. Ha az ügyfélhez 
nem jut el a kulcs, a kiszolgáló várna hiába, és számítástech- 
nikai körökben - mint tudjuk - még a várakozás sincs ingyen. 


Szakaszkulcsok (Session Tickets) 

A való világban ez kicsit másként működik. A szakaszkulcsot 
a KDC csak az ügyfélnek küldi el, mégpedig úgy, hogy a 
visszaküldött szeretetcsomagba - az ügyfél hosszú távú kul- 
csával titkosított szakaszkulcs mellé - beletesz egy, a kiszol- 
gáló számára titkosított adatstruktúrát, amely a szakaszkulcs 
mellett még más hasznos információkat is tartalmaz (amit 
persze az ügyfél se visszafejteni, se módosítani nem képes). 


Szeretnék beszélni ,B"-vel 


MY 1 





KDC 









Szakaszjegy 


KÁSa) K. (Su, jegyadatok) 


5 A KDC működés közben (K, az ügyfél, Kg a kiszolgá- 
ló hosszú távú kulcsa, S ,g a KDC által a jövendő kapcso- 
lathoz generált szakaszkulcs) 


Ezt a beágyazott adatcsomagot hívjuk szakaszjegynek (sessi- 
on ticket), mégpedig azért, mert az ügyfél ezt a jegyet bemu- 
tatva tudja majd felvenni a kapcsolatot a kiszolgálóval. A KDC 
nem foglalkozik azzal, hogy az üzenetek valóban eljutnak-e a 
címzetthez, ugyanis semmi baj nem történik, ha a válasz el- 
veszik - legfeljebb az ügyfél később újabb kulcsot kér. 

Lássuk, mihez kezd az ügyfél a visszakapott csomaggal. 
Egyrészt, a saját hosszú távú kulcsával kicsomagolja a sza- 
kaszkulcsot, és biztonságos helyre teszi. A szakaszjegyet a 
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kulcs mellé helyezi. Amikor a konkrét kapcsolatfelvételre 
sor kerül, a szakaszkulccsal előállít egy hitelesítőt (authen- 
ticatort), majd ezt és a címzetthez érvényes szakaszjegyet 
elküldi a kiszolgálónak. A kiszolgáló a csomagból kiveszi a 
neki szóló szakaszjegyet, a saját hosszú távú kulcsával 
megfejti azt, kiveszi belőle a szakaszkulcsot és jegy egyéb 
adatait. Ha az adatok alapján úgy dönt, hogy szóba áll az 
ügyféllel, a szakaszkulcs segítségével kicsomagolja a kapott 
hitelesítőt, ellenőrzi az időt, törli a hitelesítő egy részét, a 
maradékot a szakaszkulccsal visszacsomagolja, és visszakül- 
di az ügyfélnek. Az ügyfél a visszakapott hitelesítőt vissza- 
fejti, ellenőrzi a tartalmát és ha minden rendben ment, a 
szakaszkulcs segítségével már indulhat a titkosított kom- 
munikáció. Ráadásul a hitelesítő visszaküldésével az ügyfél 
és a kiszolgáló azonosították egymást. 


Sa( AT, idő) 


Szakaszjegy 


K:(Su, jegyadatok)) 





La eSiéd 


Sxafidő) 


5 Kerberos azonosítás (Sag a KDC által a kapcsolathoz 
generált szakaszkulcs, Kg a kiszolgáló hosszú távú kulcsa) 


A megoldás másik előnye, hogy az egyes kiszolgálóra szóló 
jegyek újra felhasználhatók, tehát az ügyfélnek nem kell 
minden kapcsolat előtt a KDC-hez fordulnia. A biztonság ér- 
dekében azonban minden jegy csak egy adott ideig érvé- 
nyes (ez az idő alapértelmezésben általában 8 óra), melyet 
a jegy adatmezőjében tárolunk. Az érvényességi idő lejárta 
után az ügyfél kénytelen lesz megújítani a jegyet. Ha az 
ügyfél kilép a rendszerből, a számítógépén tárolt jegyek el- 
vesznek, tehát belépéskor mindenképpen szükség lesz új 
szakaszjegyek kérésére. 


Jegy a jegyekhez (Ticket-Granting Ticket - TGT) 

A felhasználók hosszú távú kulcsát a jelszóból állítják elő, 
mégpedig egy egyirányú titkosító, úgynevezett , hash" al- 
goritmus segítségével. A szabvány szerint minden Kerberos 
implementációnak ismernie kell a DES-CBC-MD5 kódolást 
(ez egy kriptográfiai módszer a hash előállítására) . 

A KDC adatbázisában megtalálható az összes tartományi 
felhasználó és számítógép hosszú távú kulcsa. Amikor Alice 
a munkaállomásán bejelentkezik, az általa beírt jelszóból 
előáll egy kulcs, amit a bejelentkezéshez használni fog. A 
KDC ugyanezt a kulcsot a saját adatbázisából veszi, így lesz 
képes azonosítani a felhasználót. 

A hosszú távú kulcsot egy munkamenetben mindössze egy- 
szer állítják elő, mégpedig akkor, amikor a felhasználó elő- 
ször bejelentkezik a rendszerbe. A bejelentkezés után a fel- 
használó kap egy speciális szakaszjegyet, amit azután min- 
dennemű kapcsolat felépítéséhez és kezdeményezéséhez 
használhat (és használnia is kell) . 

Mint mondtuk, a KDC az, aki az ügyfél és a kiszolgálók kö- 
zötti azonosítást lehetővé teszi. Az ügyfél tehát, mielőtt a 
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kiszolgálóhoz menne, a KDC segítségére szorul (szakaszje- 
gyet kell kérnie tőle a kiszolgálóhoz), ezért a legelső sza- 
kaszjegy, amire az ügyfélnek szüksége van, magához a KDC- 
hez szól, hogy ezentúl ne kelljen a hosszú távú kulcsot 
használva azonosítania magát. 

Ez a speciális szakaszjegy a Ticket-Granting Ticket (TGT), 
azaz a jegy a jegyekhez. Az ügyfél a bejelentkezés után e 
jegy bemutatásával kérhet további szakaszjegyeket a KDC- 
től. A TGT egyébként teljesen hasonló az általános szakasz- 
jegyekhez, hiszen tulajdonképpen ez is csak egy jegy egy 
szolgáltatáshoz (mégpedig a KDC jegyárusához). 

Amikor tehát a felhasználó azonosítása megtörtént, a KDC a 
további jegyek kiadásához generál Alice számára egy sza- 
kaszkulcsot (ez a bejelentkezési szakaszkulcs, logon session 
key). Ezt a szakaszkulcsot a felhasználóra vonatkozó adatok- 
kal együtt becsomagolja és a saját hosszú távú kulcsával tit- 
kosítja. Ez a titkosított adatcsomag maga a TGT. Látható, 
hogy a felhasználó a TGT-t se elolvasni, se módosítani nem 
tudja, hiszen azt a KDC titkosította, önmagának. A KDC 
ezután a szakaszkulcsot betitkosítja a felhasználó hosszú tá- 
vú kulcsával is (hiszen a kulcshoz azért neki is hozzá kell fér- 
nie), és némi, a TGT-re vonatkozó információ mellett az 
egész csomagot visszaküldi a felhasználónak. 

Az ügyfél tehát válaszul kap egy csomagot, ami két részből 
áll: az első rész a felhasználó saját hosszú távú kulcsával tit- 
kosított információ és a szakaszkulcs egy példánya, amit a 
KDC-vel való további kapcsolatok titkosítására majd felhasz- 
nálhat. A második rész a KDC kulcsával titkosított TGT, ami- 
vel pedig azonosíthatja magát. Az ügyfél a dekódolt szakasz- 
kulcsot, az adatokat, és magát a TGT-t biztos helyre menti. 
A felhasználó jelszavát és hosszú távú kulcsát ekkor el is fe- 
lejthetjük, hiszen a KDC felé a TGT, más kiszolgálók felé pe- 
dig a majdan KDC-től kapott szakaszjegyek segítségével jö- 
het létre a kapcsolat. 


Hitelesítés tartományok között 

A KDC feladata kettős: egyrészt, a hitelesítő szolgáltatás 
(Authentication Service) TGT-ket, másrészt a jegykiszolgáló (Ti- 
cket-Granting Service) a már TGT-vel jelentkező ügyfelek részé- 
re szakaszjegyeket gyárt. Ez a kettősség teszi lehetővé, hogy a 
Kerberos azonosítás tartományi határokat átlépve is működhes- 
sen. Lehetséges, hogy az ügyfél az egyik tartomány KDC-jétől 
kapott TGT segítségével egy másik tartomány KDC-jétől kérjen 
szakaszjegyet egy szolgáltatáshoz. A KDC szakaszjegyeket min- 
dig csak a saját tartományába tartozó szolgáltatásokhoz adhat, 
hiszen csak a saját tartományában található felhasználók és szá- 
miítógépek hosszú távú kulcsával rendelkezik. 

A dolog megértéséhez kezdjük a legegyszerűbb esettel: le- 
gyen két tartományunk, Pest és Buda. Ha azt szeretnénk, 
hogy a két tartomány között létrejöhessen Kerberos hitele- 
sítés, a tartományok között is meg kell osztanunk egy kö- 
zös titkot, egy speciális kulcsot. Ez a tartományok közötti 
kulcs, az inter-domain key. 

A Windows 2000 a tartományok közvetlen megbízotti viszo- 
nyának kialakításakor ezt a tartományok közötti Kerberos kul- 
csot is létrehozza. A Windows 2000 tartományok között meg- 
bízotti viszony automatikusan alakul ki, amikor egy tartomá- 
nyi fában a meglévő tartomány(ok) mellé újat hozunk létre - 
természetesen csak a , szomszédos" tartományok között, hi- 
szen a megbízotti viszonyok átlátszósága, tranzitív jellege 
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miatt - néhány kivételtől eltekintve - a további közvetlen 
megbízotti viszonyok (értsd: mindenki mindenkivel) létreho- 
zása nem szükséges. Az egymással közvetlen megbízotti vi- 
szonyban álló (szomszédos) Windows 2000 tartományok tehát 
rendelkeznek közös tartományok közötti kulccsal. 
Gondoljunk csak bele, mit jelent ez a plussz egy kulcs: 
mindössze annyit, hogy egy tartomány KDC-je a tartományi 
fiókokon kívül még egy valakinek a hosszú távú kulcsát is is- 
meri: ez pedig a másik tartomány KDC-je. Magyarán, Pest 
KDC-jétől ugyanúgy kérhetünk szakaszjegyet Buda KDC-jé- 
hez, mint ahogy bármilyen más szolgáltatáshoz. 
Főhősünk, Fű Benő Pesten ül számítógépe előtt, és szeret- 
né elérni Gipsz Jakab számítógépének CD-meghajtóját, aki 
a Rózsadombon (Budán) lakik. Benő Pest KDC-hez fordul a 
kérésével. Pest KDC felismeri, hogy a kérés Buda KDC-re 
tartozik, ezért Benő tőle csak egy hivatkozó jegyet (refer- 
ral ticket) kap, aminek segítségével Buda KDC-nél érdek- 
lődhet. (Ezt a jegyet a tartományok közötti kulccsal titkosítot- 
ták.) Benő a jeggyel átússza a Dunát, és jelentkezik Buda 
KDC-nél, aki az általa is ismert tartományok közötti kulccsal 
ellenőrzi a jegy helyességét, majd egy hagyományos, immár 
a rózsadombi Gipsz Jakab szolgáltatásához szóló szakaszje- 
gyet ad Benőnek. Benő ezzel a jeggyel azután bátran jelent- 
kezhet a Rózsadombon, hiszen az pontosan olyan, mintha 
azt más, tőzsgyökeres budai felhasználó kapta volna. 
Ha kettőnél több tartományunk van, bonyolódik a helyzet. 
Általában nincs értelme annak, hogy minden tartományt min- 
den tartománnyal megbízotti viszonyba hozzunk, hiszen a 
Windows 2000 tartományok közötti megbízotti viszony tran- 
zitív, átlátszó. Ha az ügyfél és az általa igényelt szolgáltatás 
olyan két különböző tartományban található, amelyek nem 
szomszédosak (azaz nem állnak egymással közvetlen megbízot- 
ti viszonyban), akkor az ügyfél az előző esethez hasonló mó- 
don ,végigutazhatja" a fát, míg eléri a céltartományt. 

Lássunk egy példát: adott három tartomány, Debrecen, 

Pécs és Budapest. A fa csúcsán Budapest található, azaz 

Debrecen és Pécs egymással nem áll közvetlen megbízotti 

viszonyban (Debrecennek és Pécsnek tehát nincs közös tar- 

tományok közötti kulcsa). 

Fű Benő pécsi előadása alkalmával szeretné elérni az azóta 

Debrecenbe költöző, Gipsz Jakab számítógépét: 

1. Benő Pécs KDC-től jegyet kér a debreceni Gipsz Jakab 
számítógépéhez. Pécs KDC erre csak egy, a Budapest 
KDC-hez szóló, a Pécs-Budapest közös kulccsal titkosí- 
tott hivatkozási jeggyel válaszol (mással nem is tudna, 
mert Debrecennel nincs közös kulcsa). 

2. Benő a jeggyel Budapest KDC-hez fordul, aki ismét csak 
egy hivatkozási jegyet tud adni: a jegy ezúttal Debrecen 
KDC-hez szól (a Budapest-Debrecen kulccsal titkosítva) . 

3. Benő továbbutazik, és az utoljára kapott jegyet bemu- 
tatja Debrecen KDC-nek, aki mosolyogva átnyújtja Be- 
nőnek a Gipsz Jakabhoz érvényes szakaszjegyet. 

4. A szakaszjeggyel Benő a következő nyolc órában már ví- 
gan és közvetlenül elérheti Gipsz Jakab számítógépét. 
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Alprotokollok 

A Kerberos protokoll valójában három alprotokollból áll: 

1. Authentication Service Exchange (AS): hitelesítő szol- 
gáltatás, ez azonosítja a felhasználót és állítja elő 
számára a TGT-t 

2. Ticket-Granting Service Exchange (TGS): a jegykiszol- 
gáló szolgáltatás, ami az érvényes TGT-ket bemutató 
ügyfelek számára más szolgáltatásokhoz érvényes sza- 
kaszjegyeket készít 

3. Client/Server Exchange (CS): az ügyfél és a kiszolgáló 
közötti azonosítás, a TGS-től kapott szakaszjegy alapján 


AS Exchange 

Az első két protokoll a kapcsolatot kezdeményező ügyfél és 
a KDC, az utolsó pedig az ügyfél és az általa áhított szol- 
gáltatást nyújtó kiszolgáló között zajlik. A protokollok 
megértéséhez vegyük ismét Alice-t és Bob-ot. Alice beje- 
lentkezik a hálózatba és szeretne hozzáférni Bob egy szol- 
gáltatásához. Mindegyik protokoll kérésből (KRB xxx REO) 
és válaszból (KRB xxx REP) áll. 

Az AS kérés és válasz tulajdonképpen Alice bejelentkezése. 
A kérésben Alice elküldi a KDC-nek a saját adatait, az igé- 
nyelt szolgáltatás leírását (TGT-t szeretne) , valamint a jelszó- 
ból képzett hosszú távú kulccsal (K4) titkosított hitelesítőt. 
A KDC megkapja a csomagot, a titkosítatlan adatokból kide- 
rül számára, hogy Alice próbál meg bejelentkezni. Az adat- 
bázisából megkeresi Alice hosszú távú kulcsát (K4) és meg- 
próbálja dekódolni a hitelesítőt, ezzel azonosítja Alice-t. Ha 
sikerült, és a benne található adatok (például az idő) ér- 
vényesek, a KDC generál egy bejelentkezési szakaszkulcsot 
(SAtice): és előkészíti a választ: 

A KDC a szakaszkulcsot (S47ice) és néhány egyéb hasznos 
adatot saját (KrGs) kulcsával betitkosítja - ez a TGT. A 
szakaszkulcsot Alice hosszú távú kulcsával (K4) is betitko- 
sítja, hogy Alice is hozzáférjen a szakaszkulcshoz. Az 
egészhez hozzáragaszt még némi nyílt információt a TGT- 
vel kapcsolatban (hiszen a TGT-ben tárolt adatokhoz Alice 
nem jut hozzá), és válaszként elküldi Alice-nak. 


Gent ád 


TGT-t kérnék Ka(adatok, idő) 


KRB AS REO 


KDC 
KRB AS REP 





Ka(Sxa), adatok 


Kiss(Swr, jegyadatok) 





5 Az AS (Authentication Service) protokoll (S A riee a KDC 
által a TGT-hez generált szakaszkulcs, K, Alice; Kras 
a KDC hosszú távú kulcsa) 


Amikor Alice megkapja a pozitív választ, a saját hosszú tá- 
vú kulcsával (K4) dekódolja a szakaszkulcsot (S4/ce) 
majd az adatokkal a komplett TGT-vel együtt elmenti. 
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TGS Exchange 

Az AS protokoll segítségével Alice jogot formált arra, hogy 
jegyet vásárolhasson a tartomány szolgáltatásaihoz. Ezután 
a szakaszjegyek megváltása következik: 


eat éj 


Jegyet kérnék 









s Saucc(adatok, idő) 
a 
KRB TGS REO 
KDC 
KRB TGS REP 
gége Szakaszjegy B-hez 
cet 
Kaucr(Sas), adatok K.(Su, jegyadatok) 
9 A TGS (Ticket-Granting Service) protokoll (S A rjee a KDC 


által a TGT-hez generált szakaszkulcs, Sag Alice és Bob 
kapcsolatához generált szakaszkulcs, Kg Bob; Krcs a KDC 
hosszú távú kulcsa) 


Alice a TGS kérésben meghatározza a kívánt szolgáltatást, 
amihez a jegyet kéri. Alice a bejelentkezési szakaszkulccsal 
(SArice) előállít egy hitelesítőt, és az egészhez mellékeli az 
elmentett TGT-t. A KDC a saját titkos kulcsával (Krs5) dekó- 
dolja a TGT-t és így hozzájut Alice bejelentkezési szakaszkul- 
csához (S4/jce) - Ezzel a kulccsal már ki tudja nyitni a hitele- 
sítőt, és a szokásos módszerrel ellenőrzi a kérés hitelességét. 
Ha az ellenőrzés során sikerrel járt, az adatbázisában megke- 
resi a kívánt szolgáltatás (Bob) hosszú távú kulcsát (Kg) és 
előállít egy egyedi szakaszkulcsot, amit majd Alice és Bob 
fog használni a későbbi párbeszédeik során (S4e). 

Az új szakaszkulcsot (Se) titkosítja az Alice által küldött 
szakaszkulccsal (S4rijce), és a titkosított kulcshoz hozzá- 
csap még némi információt a következő szakaszjegyről. A 
szakaszjegy az új szakaszkulcsból (S4g) és számos, Bob 
számára hasznos információból áll (pl. Alice jogai, csoport- 
tagsága, stb.) - mindez természetesen Bob hosszú távú kul- 
csával (Kg) titkosítva, hogy csak ő tudja elolvasni. 
Amikor Alice megkapja a választ, a bejelentkezési szakasz- 
kulcsával (S4/ice) kibontja a Bob felé használható új sza- 
kaszkulcsot (549). A szakaszkulcsot, a szakaszjegyet, és a 
rá vonatkozó adatokat ugyancsak elmenti. 


CS Exchange 

Alice ezután már felveheti a közvetlen kapcsolatot Bob-bal. 
Alice először is, a Bob-féle szakaszkulccsal (S4g) előállít 
egy hitelesítőt, majd azt a Bob-hoz érvényes szakaszjeggyel 
együtt elküldi Bob-nak. 

Bob megkapja a csomagot, saját hosszútávú kulcsával (KB) 
kinyitja a szakaszjegyet, és megszerzi belőle a szakaszkul- 
csot (S4g), valamint hasznos információkhoz jut Alice-ről. 
A szakaszkulcs segítségével Bob már képes kibontani és el- 
lenőrizni a hitelesítőt is. 
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5 A CS (Client-Server) protokoll (S ,g Alice és Bob kapcso- 
latához generált szakaszkulcs, Kg Bob hosszú távú kulcsa) 


Ha a kölcsönös hitelesítést elvárjuk, akkor utolsó lépésben 
Bob-nak is bizonyítania kell Alice felé, hogy ő valóban Bob. 
Ezt a klasszikus módon teszi: fogja az Alice által kapott hi- 
telesítőt, megváltoztatja a tartalmát (például kiveszi az 
adatokat és csak az időt hagyja benne), majd a szakasz- 
jeggyel (Sa) titkosítva visszaküldi. 

Amikor Alice megkapja ezt az üzenetet, biztos lehet benne, 
hogy azt Bob küldte, hiszen ki tudta nyitni - és vissza tud- 
ta csomagolni - a szakaszkulccsal titkosított hitelesítőt. A 
szakaszkulcshoz viszont csakis a szakaszjegyből juthatott 
hozzá, ami viszont Bob saját hosszú távú kulcsával volt tit- 
kosítva. Konklúzió: aki a hitelesítőt így vissza tudta külde- 
ni, az ismeri Bob hosszú távú kulcsát, következésképpen 
vagy Bobbal, vagy a KDC-vel állunk szemben (de a KDC nem 
tenne ilyen gonoszságot ;-) ). 
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A Microsoft és más, vele együttműködő cégek több olyan cél- 
kitűzést fogalmaztak meg, melyek elősegítik a nagykiterjedé- 
sű PC-hálózatok tulajdonlási költségének (TCO) csökkentését. 
A TCO messze meghaladja egy elosztott PC-hálózat hardver- és 
szoftvereszközeinek beszerzési árát. A TCO-ba beletartoznak az 
üzembehelyezés, a karbantartás, a rendszerfelügyelet, a kép- 
zés, a telefonos és helybeni terméktámogatás költségei, vala- 
mint a hardver- és szoftverfrissítésekkel kapcsolatos kiadások. 
E költségcsökkentő kezdeményezések közül az egyik legfonto- 
sabb a WBEM (Web-Based Enterprise Management - nagykiterje- 
désű rendszerek Web-alapú felügyelete) , amely a felügyeleti inf- 
rastruktúrára vonatkozó szabványokat fogalmaz meg, és lehe- 
tővé teszi többféle hardver- és szoftverfelügyeleti rendszerből 
származó információk összegzését. Ez az információ aztán fel- 
használható a rendszerfelügyeleti alkalmazásokban. A WBEM a 
CIM (Common Information Model — közös információ-modell) sé- 
mán alapul, amely a DMTF (Distributed Management Task Force 
- elosztott felügyelet munkacsoport) által létrehozott szabvány. 
A Microsoft Windows Management Instrumentation (WMI, Win- 
dows felügyeleti eszközkészlet) WBEM-kompatibilis, és a Win- 
dows 2000 operációs rendszer beállításairól, állapotáról és mű- 
ködéséről összefüggő, gazdag információkkal szolgáló modellt 
biztosít. A Windows 2000 más rendszerfelügyeleti szolgáltatá- 
saival együtt használva a WMI leegyszerűsítheti az integrált 
felügyeleti alkalmazások fejlesztését, lehetővé téve a gyártók- 
nak skálázható, hatékony felügyeleti rendszerek készítését. 
Cikkünkben először a WBEM áttekintésével és kialakulásával, 
majd a WBEM szabványos összetevőivel, és a WBEM-kompa- 
tibilis Windows felügyeleti architektúrával foglalkozunk. Vé- 
gül a WMI funkciók és más Windows felügyeleti szolgáltatá- 
sok együttműködésére mutatunk példákat. 


A WBEM áttekintése 

A WBEM a nagykiterjedésű hálózatok felügyeleti információi- 
nak elérését és megosztását szolgáló szabványos, de nem sza- 
badalmazott (vagyis nyílt) megoldások kifejlesztését célzó 
kezdeményezés. A WBEM olyan megoldásokat fog eredmé- 
nyezni, melyek lehetővé teszik a különböző forrásokból szár- 
mazó felügyeleti adatok összegyűjtését, összekapcsolását és 
összesítését, és ezzel gazdagabb és pontosabb képet adhat- 
nak a nagyvállalati környezetről. A WBEM kezdeményezés cél- 
kitűzései között szerepel a nagykiterjedésű hálózatok állapo- 
táról szóló, és azok felügyeleti adatainak összegyűjtésével 
kapcsolatos problémák megoldása. Ezek a hálózatok számos 
hardvergyártó eszközeit, többféle protokollt és operációs 
rendszert, és rengeteg elosztott alkalmazást tartalmazhatnak. 
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a Nagykiterjedésű hálózatban megtalálható tipikus 
protokollok és eszközök. 


A nagykiterjedésű hálózatok felügyelete általában különféle 
eszköztípusok változatos protokolljaihoz és csatolófelületei- 
hez kötődik (például a Simple Network Management Protocol 
(SNMP) a hálózatok felügyeletére, a Desktop Management In- 
terface (DMI) az asztali gépek felügyeletére szolgál) . A WBEM 
szerint a nagykiterjedésű hálózatok felügyeletéhez olyan 
eszközökre van szükség, melyek együttműködnek annak ér- 
dekében, hogy a felügyeleti információk összegyűjtésére egy 
egyszerű, közös modellt alkossanak. A WBEM biztosítja ezt a 
közös modellt és adatforrást, melyek bővíthetők, hogy képe- 
sek legyenek együttműködni a meglévő hálózati összetevők- 
kel, eszközökkel és protokollokkal. 


Rendszerfelügyelet 





5 A WBEM architektúra. 


A WBEM nem böngészőalapú eszköz, nem felhasználói felület, 
nem adattároló, nem hálózatfelügyeleti protokoll, nem objek- 
tummodell, és nem is regisztrációs adatbázist, címtárat, vagy 
fájlrendszert helyettesítő eszköz. A WBEM egy kezdeményezés, 
mely a nagykiterjedésű hálózatok felügyeletéről szóló szabvány- 
gyűjtemény létrehozását tűzi ki célul. A felügyeleti szabványok: 
"0 Leírják a felügyelt objektumokról szóló információk 
eléréséhez szükséges struktúrákat és konvenciókat. 
"2 Támogatják az információk központosítását, így a külön- 
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féle ügyfelek és felügyeleti eszközök képesek adatokat 
szolgáltatni, visszakeresni és elemezni. 

"B Támogatják, hogy hitelesítés után bárhonnan a hálózat- 
ról hozzá lehessen férni a felügyelt objektumokhoz, így 
azok elemezhetők és manipulálhatók. 


A WBEM kialakulása 

A WBEM ajánlást 1996-ban a Microsoft, a Compag Compu- 
ter, a BMC Software, a Cisco Systems és az Intel vezetésé- 
vel több cég hozta létre. Az elképzelés olyan nyílt felügye- 
leti környezet kialakítása volt, melyben a lehető legtöbb 
meglévő technológia és szabvány felhasználásával az 
összes felügyeleti rendszer és alkalmazás elérheti, szabá- 
lyozhatja és megoszthatja egymással és az eszközt 
felügyelő ügynökkel (agent) a felügyeleti információkat. 
Sok szempontból ez a meghatározott cél a World Wide Web 
tapasztalatait vette alapul, ahol az Interneten levő eszkö- 
zök az információk forrásaiként és használóiként anélkül 
szerepelhetnek, hogy tudnák egymásról, hogy a másik mi- 
lyen környezetben működik. A nyílt felügyeleti rendszer 
létrehozásában a webes technológiák és a megszokott 
felügyeleti eszközök együttes használatának lehetősége 
miatt lett a kezdeményezés neve Web-Based Enterprise 
Management (WBEM). 

Az alapítótagok a Distributed Management Task Force-szal 
(DMTF) együttműködve kifejlesztették a bármely felügyele- 
ti eszköz (például SNMP, DMI) definiálását és elérését szol- 
gáló környezetfüggetlen eszközkészlet részletes leírásának 
első verzióját. Ennek fő eleme egy adatleíró eljárás volt, 
amely később - immár a DMTF szabványaként - Common In- 
formation Model (CIM) néven vált ismertté. 

Az eredetileg HyperMedia Management Schema (HMMS) pro- 
jekt néven futó CIM specifikáció megadta a modellezési 
nyelvet, a névadási és hozzárendelési eljárásokat, melyeket 
az adatszolgáltatóktól és más felügyeleti modellekből szár- 
mazó információk összegyűjtésére és átvitelére használtak. 
A CIM séma szolgáltatja az érvényes modell-leírásokat és az 
információs keretrendszert, megad egy tulajdonságokkal és 
asszociációkkal rendelkező osztálykészletet, ezzel lehetővé 
teszi a felügyelt környezet információinak rendezését. 

A DMTF tulajdonát képezi a CIM specifikációja és a CIM séma, 
melyeket a hálózatfelügyeleti adatok elérésének és megosztá- 
sának iparági szintű szabványaként határoztak meg. 

Az 1996-tól 1998-ig tartó időszakban a Microsoft kidolgoz- 
ta a WBEM Windows-os megvalósítását. Ebbe a munkába 
beletartozott a WBEM szoftverfejlesztő készlet (SDK), a kü- 
lönböző CIM összetevők és CIM-kompatibilis adatszolgálta- 
tók kifejlesztése is. 

1998. júniusában a DMTF bejelentette, hogy átvette a 
WBEM kezdeményezést az alapító vállalatoktól. Jelenleg a 
DMTF a WBEM kezdeményezés megvalósítására irányuló erő- 
feszítések központja, és szervezeti keretet biztosít a WBEM- 
kompatibilis eljárások és szabványok fejlesztésében való 
széleskörű iparági részvételhez. A WBEM-alapú szabványok 
egyedi megvalósítása (például a Microsoft Windows Manage- 
ment Instrumentation SDK (volt WBEM SDK)) továbbra is az 
őket kifejlesztő gyártók feladata. A WBEM kezdeményezés 
átvételekor a DMTF beleegyezett, hogy a meglevő WBEM el- 
járásokat, például a Microsoft CIM megvalósítását referen- 
cia-példaként használja. A DMTF beleegyezett abba is, hogy 
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fenntartja a WBEM ígérte platformfüggetlenséget, és elzár- 
kózik minden megvalósítási függés (például adott program- 
nyelv használata) megadásától bármely követelményben. 


A szabványos WBEM összetevők 
Jelenleg két fő részből áll a WBEM (további szabványok vár- 
hatók, például az XML használata a CIM objektumok plat- 
formfüggetlen megosztására): 
"8 A CIM specifikáció, mely meghatározza a WBEM megva- 
lósítás követelményeit. 
"8 A CIM séma, mely meghatározza az adattároló tartalmát. 
Alapvetően a WBEM a CIM megvalósítását tűzi ki célul. A CIM 
a felügyelt objektumok objektumorientált sémája. Ezek a felü- 
gyelt objektumok a rendszererőforrások megjelenítési formái, 
és a séma minden általuk szolgáltatott adathoz egyszerű 
adatleíró eljárást nyújt. A WBEM meghatározza, hogyan kell 
az adatokat megjeleníteni, és tartalmaz egy folyamatszab- 
ványt, ami meghatározza az összetevők egymásra hatását. 
A CIM séma a központi (core) modellből, és a közös (com- 
mon) modellekből áll. A központi modell az összes felügye- 
leti tartományra érvényes, a közös modellek különböző 
felügyeleti tartományok (számítógépek, hálózat, adatbázis, 
alkalmazás, egyéb eszközök) közös információit adja meg. 
Maga a séma bővíthető, a bővítő-sémák a közös séma tech- 
nológiafüggő kiegészítései. 


A Microsoft WBEM megvalósítása—a WMI 
A WMI (Microsoft Windows Management Instrumentation — 
Microsoft Windows felügyeleti eszközkészlet) WBEM-kompati- 
bilis, és CIM alapokon támogatja az egységes rendszer- és 
alkalmazásfelügyeletet. A WMI a Microsoft Windows felügye- 
leti szolgáltatások egyik fő összetevője. A Windows felügye- 
leti szolgáltatások közé tartoznak az Active Directory hely- 
meghatározó és házirendszolgáltatásai, a Microsoft Manage- 
ment Console (MMC) megjelenítési szolgáltatásai, és a Win- 
dows Scripting Host (WSH) automatizálási képességei is. 

A WMI segítségével csökkenthetők a rendszerek összetevői- 

nek felügyeleti költségei, és a karbantartásukra fordított 

idő. A WMI a következőket biztosítja: 

- Gazdag és összefüggő információmodellt a Windows 98 
és Windows 2000 működéséről, állapotáról és beállítá- 
sairól (a Windows NT 4.0-hoz és a Windows 95-höz is le- 
tölthetők a WMI fő összetevői). 

8 COM API-t, amely egyetlen felületen elérhetővé teszi az 
összes felügyeleti információt. 

"8 Együttműködést más Windows 2000 felügyeleti szolgál- 
tatásokkal. Ez az eszközök gyártóinak egyszerűbbé teszi 
az integrált felügyeleti alkalmazások készítését. 

"2 Rugalmas architektúrát, mely biztosítja a gyártóknak az 
információmodeltl kiterjesztését új eszközökhöz, alkal- 
mazásokhoz, vagy más fejlesztésekhez írt kódmodulok- 
kal (WMI szolgáltatókkal) . 

"8 Részletes eseményarchitektúrát, mely lehetővé teszi a 
felügyeleti információk változásainak azonosítását és 
összesítését, más felügyeleti információkkal való össze- 
hasonlítását és összekapcsolását, valamint a helyi vagy 
távoli felügyeleti alkalmazásokhoz való továbbítását. 

-8 Gazdag lekérdezőnyelvet, mely biztosítja az információs 
modell részletes lekérdezését. 

8 Scriptelhető API-t, melynek segítségével a felügyeleti 
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alkalmazások fejlesztéséhez használható a Microsoft Vi- 

sual Basic vagy a Windows Scripting Host (WSH). 
A távoli események kezelésének és az információmodell 
gazdag lekérdezőnyelvének együttes használata például 
biztosíthatja az összetett felügyeleti problémák megoldá- 
sát. Az a lehetőség, hogy ezek a megoldások Visual Basic 
vagy WSH parancsfáljok használatával elkészíthetők, új táv- 
latokat nyitnak a Windows NT felügyeletéhez. 


A WMI architektúra 

A WBEM három részből álló architektúrával biztosítja a 
felügyeleti adatok összegyűjtését és elosztását. A WMI-ben 
ez az architektúra a szabványos objektum-definíciókból 
(CIM-kompatibilis objektum-tároló), a felügyeleti adatok 
elérésének és elosztásának szabványos protokolljából 
(COM/DCOM; de más protokollok használata is lehetséges), 
és egy vagy több Win32 WMI adatszolgáltatóként működő 
dll-ből áll. A WMI szolgáltató eszközkészlet adatokat bizto- 
sít a CIM séma részeinek. 





0 A WMI architektúra 


A WMI funkcionalitást biztosító folyamat (process) a 
WinMgmt.exe. Ez a futtatható fájl biztosítja a WMI-t alko- 
tó CIM objektumtároló (object repository) , CIM objektumke- 
zelő (Object Manager) , és API-k működését. 


A CIM objektumkezelő 

A CIM objektumkezelő a Microsoft WBEM megvalósításának 
egyik fő része. A WBEM fő célja az adatok egységes megjelení- 
tése, és azok objektum-orientált módon való beágyazása a CIM 
objektum-tárolóba. A CIM objektumkezelő a tárolóban tárolt, 
felügyelt objektumokhoz gyűjtési és kezelési felületet tartalmaz. 
A CIM objektumkezelő nem éri el közvetlenül az információ- 
kat, hanem a WMI szolgáltatók gyűjtik össze az erőforrástól 
(felügyelt objektumtól) azokat, majd a WMI API-n keresztül 
a felügyeleti alkalmazások számára elérhetővé teszik őket. 


A WMI szolgáltatók 

A WMI szolgáltatók (WMI provider) közvetítőként működnek a 
CIM objektumkezelő, és egy vagy több felügyelt objektum kö- 
zött. Amikor a CIM objektumkezelőtől a felügyeleti alkalma- 
zás egy, a tárolóban nem elérhető információt, vagy általa 
nem támogatott eseményekről szóló értesítéseket kér, továb- 
bítja a kérést a szolgáltatóhoz. Ezután a szolgáltató biztosít- 
ja a kért információt, vagy az eseményről szóló értesítést. 

A WMI az alábbi szolgáltatókat tartalmazza: 

0 Win32 szolgáltató 
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WDM szolgáltató 

Eseménynapló szolgáltató 

Rendszerleíró adatbázis (registry) szolgáltató 
Teljesítményfigyelő (Performance Counter) szolgáltató 
Active Directory szolgáltató 

Windows Installer szolgáltató 

7 SNMP szolgáltató 

Más gyártók a WMI SDK alkalmazásával készíthetnek egye- 
di szolgáltatókat, melyek együtt tudnak működni a saját 
környezetük egyedi felügyelt objektumaival. 

A WMI eljárásai nem a meglévő felügyeleti szabványok (pél- 
dául SNMP, DMI, CMIP) lecserélését szolgálják, és alkalmazá- 
suk nem jelenti a szabadalmazott vagy platformfüggő keret- 
rendszerek (például NDS) kiirtását. A WMI tulajdonképpen 
kiegészíti ezeket azzal, hogy integrációs felületet biztosít, 
melyen keresztül bármely forrásból származó adat elérhető. 


PA Ó 


Pod 


5) 


Az események kezelése 

Az eseményekre való figyelmeztetés fontos lehetőség a 
WMI-ben, mert ez biztosítja, hogy az összetevők felderítsék 
a hardverrel vagy szoftverrel kapcsolatos eseményeket 
és/vagy hibákat. Ezután az esemény keresztülhalad a WMI 
architektúrán a megfelelő felügyeleti összetevőhöz, mely 
végrehajthatja a helyesbítő eljárást. 

A WMI-ben az esemény egy történés, amely vagy előre 
megadott, valós világban létrejövő feltételeknek (kívülről jövő 
esemény), vagy a CIM tárolóban bekövetkezett változásoknak 
(belülről jövő esemény) felel meg. Egy esemény megtörténte 
után egy eseményszolgáltató értesíti a CIM objektumkezelőt, 
mely továbbítja az eseményt egy vagy több bejegyzett címzett- 
nek, azaz az eseményfigyelőknek (event consumer). Az ese- 
ményfigyelők bejegyezhetik a CIM objektum-kezelőben, hogy 
adott típusú értesítéseket kapjanak, az eseményszolgáltatók pe- 
dig bejegyezhetők, hogy bizonyosfajta értesítéseket küldjenek. 
Az eseményfigyelők az eseményszolgáltatóktól független műkö- 
dése érdekében a CIM objektumkezelő közvetítőként szerepel, 
megfelelteti egymásnak a bejegyzett figyelőket és a megadott 
szolgáltatókat, és továbbítja a megfelelő eseményeket. 

Az eseményfigyelők anélkül is bejegyezhetik magukat, hogy 
tudnák, mi szolgáltatja az eseményeket és értesítéseket. A 
bejegyzéshez ezek a figyelők egy szűrőt adnak meg, mely a 
WOL (WMI Guery Language -— WMI lekérdezőnyelv) használa- 
tával készül el. Ez írja le azokat a feltételeket, melyek lét- 
rejöttekor a figyelő értesítést akar kapni. 


A WMI lekérdezőnyelv 

A WOL az SOL olyan , nyelvjárása", mely eseményekről szóló 
értesítéseket, és más WBEM kompatibilis funkciókat támoga- 
tó bővítményeket tartalmaz. Amikor a figyelők bejegyzik ma- 
gukat az eseményekről szóló értesítések címzettjeként, tulaj- 
donképpen egy lekérdezést adnak meg, ami leírja az esemény 
típusát és a feltételeket, melyek teljesülésekor értesítést kap- 
nak. A WMI SDK-ban definiált WOL használható értesítésszű- 
rők készítésére is. 
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WBEM-kompatibilis scriptprogramozás 
A WMI Script felületei CIM objektumkezelővel együttműködő 
parancsfájl és Visual Basic alkalmazások fejlesztésére használ- 
hatók. A WMI az alábbi nyelvek támogatását biztosítja: 
"8 Microsoft Visual Basic 
8 Visual Basic for Applications 
B Visual Basic, Scripting Edition (V8BScript) 
"B Microsoft JScript 
"9 Perl 
A CIM objektumkezelő scriptelési felületei annyiban külön- 
böznek a COM felületektől, hogy ezeket eleve a Visual Ba- 
sic, Visual Basic for Applications, Visual Basic Scripting Edi- 
tion (VBScript) és más parancsnyelvekkel való együttműkö- 
désre tervezték. A Microsoft WBEM-kompatibilis scriptelés 
az alábbi előnyöket biztosítja: 

"I Adatközpontú megközelítést alkalmaz, a CIM-et. A CIM 
modellt biztosít az eltérő információk kezeléséhez, a 
script API pedig elszigeteli egymástól az alkalmazásokat, 
és a különböző adatforrások összetett rendszerét. 

"I Biztosítja a rendszer-, hálózat-, és alkalmazásinformációk 
széleskörű lefedését. A Microsoft megvalósítás a Win32, 
SNMP, regisztrációs adatbázis, Windows Driver Model 
(WDM), Performance Monitor, eseménynapló, és ADSI szol- 
gáltatókat teszi elérhetővé. Más gyártók, például az Intel, a 
Compag, a Hewlett-Packard és a BMC Software szintén fog- 
nak készíteni termékeikhez szolgáltatókat, hogy lehetővé 
tegyék gyártófüggő eszközkészletek használatát (ez így lesz 
a Microsoft Systems Management Serverrel is). A Microsoft 
egyéb szolgáltatói jelenleg fejlesztés alatt állnak. 

8 A szolgáltató eszközkészletek könnyen bővíthetők. Az 
eszközök, a minták és a bővíthető szolgáltató architek- 
túra teljes leírása megtalálható a Microsoft WMI SDK- 
ban. Emellett a szolgáltatók fejlesztése széleskörű ipar- 
ági támogatást élvez. 

"8 Egyszerű új parancsfájlokat írni. A Microsoft WBEM-kom- 
patibilis API-t egyszerű használni, a séma pedig bön- 
gészhető és bővíthető. 


WDM Szolgáltató 
A Microsoft a WDM szolgáltatót az operációs rendszer ker- 
nel kezelésére fejlesztette ki. A WDM eszközkészlet a Win- 
dows Driver Model (WDM) architektúra része, de széleskörű 
felhasználhatósága miatt másfajta meghajtóprogramokkal 
is együtt tud működni (például SCSI és NDIS). A WMI a WDM 
szolgáltatót használja az adatok közzétételére, az eszközök 
beállítására, és az eszközmeghajtók eseményeiről szóló ér- 
tesítések szolgáltatásához. 

A WMI WDM részei az alábbi adatokat osztják szét: 

"0 Közzétett adatok: szabványos adatkészletet találunk a 
Windows 2000-rel szállított meghajtókban. 

"0 Egyedi adatok: Az OEM-ek és független gyártók meghaj- 
tóbővítései szolgáltatják ezeket. 

-b Biztonsági adatok: A Windows 2000 biztonsági leírói 
szolgáltatják ezeket. 

8 Erőforrásigényes adatok (opcionális): Néhány adat- 
gyűjtő tevékenység jelentősen befolyásolhatja a meghaj- 
tóprogram teljesítményét, ezért ezeket az adatokat csak 
akkor kell gyűjteni, amikor egy felügyeleti alkalmazás kü- 
lön kéri ezt. Amikor az adatokat használó utolsó alkalma- 
zás is befejezi a működést, a WMI jelzi a meghajtóprog- 
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ramnak, hogy fejezze be az adatgyűjtést. Azt, hogy mi az 
erőforrásigényes adat, nem a WMI, hanem a meghajtó ké- 
szítője dönti el, egy egyszerű eljárás segítségével 

"B Eseményekről szóló értesítések: Az eseményekről szó- 
ló értesítés a WMI egyik fő funkciója, mert ez teszi le- 
hetővé, hogy a meghajtók felderítsék a hardverrel kap- 
csolatos eseményeket és/vagy hibákat. A hardveresemé- 
nyekről szóló értesítéseket az eseményszűrők és a CIM 
objektumkezelő kezeli. 

A WMI azt is lehetővé teszi, hogy a felügyeleti alkalmazás 

beállításokat végezzen egy eszközön. 


A WMI működés közben - parancsfájl példák 

Végül lássunk néhány egyszerű példát a WMI működéséről. 
Nem állítjuk, hogy ezek alapján bárki is képes lesz saját, tel- 
jes körű rendszerfelügyeleti parancsfájlokat készíteni, cé- 
lunk inkább az, hogy az eddigi elméletet egy kis gyakorlat- 
tal támasszuk alá. Tekintettel a CIM objektumok óriási szá- 
mára meg sem próbálunk átfogó képet adni, csupán a leg- 
kézenfekvőbb objektumok lekérdezésére vállalkozunk. 

A példák kódját egy .vbs kiterjesztésű szövegfájlba írva lehet 
kipróbálni. A futtatás: cscript fájlnév.vbs. Így a kimenet a 
standard out-ra megy, ezáltal könnyen át lehet irányítani 
fájlba a cscript fájlnév.vbs skimenet.txt segítségével. 

Az első példánkban felépítünk egy általános eljárást, amivel 
bármelyik WMI osztályt meghívhatjuk és megfigyelhetjük 
annak összes jellemzőjét. Konkrét alkalmazás esetén persze 
nem kötelező végigmenni minden egyes tulajdonságon, elég 
csak a kiválasztottakat közvetlenül elérni. 

A minden jellemzőt listázó eljárás: 


Sub CallWMI(Provider, Output) 
Set PropSet —— 
GetObject ( "winmgmts : (impersonationLevel-—" § 


"impersonate)") . InstancesOf(Provider) 


For Each Props In PropSet 
For Each Prop In Props.Properties 


Message - Message § Prop.Name § 0" 


If IsArray(Prop) Then 
For Each Va In Prop.Value 
If Not IsNull(Va) Then 
Value - CStr(Va) 
Else 
Value — "Null" 
End If 
Message - Message t Value § "; " 
Next 
Else 
If Not IsNull(Prop.Value) Then 
Value - CStr(Prop.Value) 
Else 
Value 5 "Null" 
End If 
Message - Message t Value a "; " 
End If 


Message - Message t vbCrLf 


Next 
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Next 
OutputString - Message 
End Sub 


Az eljárás létrehoz egy példányt a Provider paraméterben 
megadott WMI osztályból, és végiglépked annak összes jel- 
lemzőjén, összegyűjtve azokat szöveges formában az output 
paraméterbe. 

Távoli gép eléréséhez a GetObject-et kell átírni a következő 
módon: 


Getobject ( "winmgmts : / /gépnév" ) 


Nézzük meg az eljárásunk használatát! 
Alapinformációk lekérése egy számítógépről: 


CallWMI "Win32 ComputerSystem", OutputString 
WScript.Echo OutputString 


A kimenetből néhány érdekesebb sor: 
CreationClassName : 


60; 
AT/AT COMPATIBLE; 


Win32 ComputerSystem; 
CurrentTimeZone : 
Description : 
Domain : NETACADEMIA; 
DomainRole : 4; 

InfraredSupported : 
PLATAN; 


True; 
Name : 
NumberofProcessors : 1; 
SystemStartupDelay : 30; 
SystemType : X86-based PC; 


És még további 100 sor... 


Látható, hogy a Win32 ComputerSystem osztály segítségé- 
vel a legalapvetőbb információkat lehet lekérni egy számí- 
tógépről. Részletesebb információkat további WMI osztá- 
lyok meghívásával lehet elérni. Nézzük meg például, mit le- 
het megtudni a hálózati kártyákról. 

Hálózati kártyák adatainak lekérdezése: 


CallWMI "Win32 NetworkAdapter", OutputString 


Kimenet: 

AdapterType : Ethernet 802.3; 

Description : Intel 21041 Based PCI Ethernet 
Adapter; 

MACAddress : 00:8B0:48:EA:75:BA; 

Manufacturer : Intel; 

PNPDeviceID : PCIWEN 10118DEV OOLl4SSUBSYIS 


00000000£REV 1113661AAA0160£58; 


PowerManagementSupported : False; 


Mit lehet tudni a videokártyáról? 


CallWMI " Win32 VideoController", OutputString 
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Kimenet: 


AdapterDACType : S3 SDAC; 
AdapterRAM : 4194304; 
Caption : SZ Inc. Trio3D/2X Display Driver Version 
3.30.10; 
CurrentBitsPerPixel : 24; 
CurrentHorizontalResolution : 


85; 


1024; 
CurrentRefreshRate : 
CurrentVerticalResolution : 768; 
DriverVersion : 4.1024.330.0010; 
MaxRefreshRate : 85; 
MinRefreshRate : 43; 


... És még további 60 jellemző. 


Ezek a példák csak a hardverrel foglakoztak. Azonban hihe- 
tetlenül sok szoftverinformáció is elérhető a WMI-n keresz- 
tül. Ízelítőül és házi feladat gyanánt a következőket javas- 
lom kipróbálásra: 

Win32 Process 

Win32 Service 

Win32 Share 

Win32 Directory 

Ráadásul ezeken az osztályokon keresztül nemcsak informá- 
ciókat érhetünk el, hanem vannak metódusaik is, amelye- 
ket meghívva az adott objektummal kapcsolatos művelete- 
ket is el lehet végeztetni. Például a Win32 Directory-nak 
van Compress metódusa, amivel egy kiválasztott állományt 
vagy könyvtárat be lehet állítani tömörítettre. Vagy a 
Win32 Process-nek van egy Terminate metódusa, amivel 
egy processzt ki lehet lőni. Ha mindehhez hozzávesszük azt 
a tényt, hogy a WMI működik távoli gépre is, akkor valóban 
fantasztikus távvezérlési lehetőség van a kezünkben. 
Megjegyzés: a Wscript.Echo metódus hibaüzenettel elszáll, 
ha a lekérdezés eredménye túl sok szöveget ad vissza. Ez a 
hiba eltűnik, ha a kimenetet fájlba irányítjuk át. 


További információk 

A Windows 2000 Server felügyeleti infrastruktúrájáról szóló 
legfrissebb információk a [1] címen találhatók meg. 

A Windows Management Instrumentation-ről (WMI) bővebb 
információ az MSDN-en a [2] címen lelhető fel. 

WBEM-ről és a DMTF-ről további információk a DMTF web- 
helyén találhatók: [3]. 

A Win32-es platformon elérhető osztályokról és azon tulaj- 
donságairól a [4] címről kiindulva lehet részletes segítsé- 
get találni. 


[1] http://www.microsoft.com/windows/server/ 
technical/management/default.asp 

[2] http://msdn.microsoft.com/downloads/sdks/ 
wmi/default.asp B 

[3] http://www.dmtf.org/ Z 

[4] http://msdn.microsoft.com/library/psdk/wmisdk/ 


clascomp 3d4j.htm 
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PING, PING, PING 

Mai élveboncolásunk első alanya egy jó nagy ping lesz. Mé- 
retét tekintve akkora, hogy semmiképpen sem fér be egyet- 
len, maximálisan 1514 bájt méretű keretbe. A kísérlet azért 
fontos számunkra, mert a való világ valós adatainak többsé- 
ge lényegesen nagyobb, mint 1514 bájt, így - mint csepp a 
tengerben - e jókora pingen felfedezhető ugyanaz az átala- 
kítási eljárás, ami minden nagyobb fájl esetén megtörténik, 
s amit a FONTOS.XLS is elszenved, ha hálózaton keresztül to- 
vábbítjuk - vagyis darabokra bomlik a feladónál, és ezekből 
áll össze a fogadónál. Ezt kapd el: 


PING —-1 10000 www.netacademia.net 


Az itt elemzett PING letölthető az újság weblapjáról, neve: 
BIGPING.CAP. 

Először madártávlatból vessünk egy pillantást az elkapott 
hálózati forgalomra: 





d Ble Edt Display Iools Options Window Help 


zlA] : mis] SI EBEBR ele] glel ale] al 2] 


fi 2.692793 
ú 2.964172 






















XEROX 000000 EOB320000100 DNS 
EOR320000100 XEROX 000000 DNS 
TNETTETTTTT] 

XEROX 000000 E0E320000100 
XEROX 000000 EOE320000100 
XEROX 000000 E0£320000100 
XEROX 000000 EOE320000100 
XEROX 000000 EOE320000100 
XEROX 000000 E0E320000100 
E0E320000100 
E0E320000100 
80£320000100 
E0OE320000100 X 
EOR320000100 
FOR320000100 
EOE320000100 XEROX 000000 IP 

XEROX 000000 EOE320000100 ICHP 


0x53:Std Ory 
Ox53:Std Ory 







4 
5 2.984202 
6 32.004230 
7 3.024258 
a 3.064314 
9 3.084342 
10 3.725245 
11 3.865442 
12 2.965583 
19 4.065724 
14 4.165865 
15 4.266006 
4.346119 
4.356133 





Echo Reply: 
ID 5 OxCESB; 
ID 5 OxCESB; 
ID 2 OxCESB; 
ID 5 OxCESB; 

























[domment For Summary 


5 A nagy ping látképe 


Jól megfigyelhető, hogy az ICMP Echo D és ICMP Echo 
Reply 2 közé további IP csomagok ékelődtek, melyekről - 
legalábbis első ránézésre - nem látszik azonnal, hogy a 
PING-hez tartoznának. Közönséges IP csomagok volnának?? 
A korábbi cikkeimben leírtaknak megfelelően egy beérkező 
hálózati csomag determinisztikus úton jut el a megfelelő 
feldolgozóegységhez, hisz minden egyes réteg pontosan 
tudja, hogy a számára feldolgozhatatlan , Number of data 
bytes remaining" adatokat hova továbbítsa. Az Ethernet ke- 
retben az Ethernet Type mező mutatja meg, hogy mit szál- 
lít az adott keret, míg például az IP-ben a Protocol mező 
végzi ugyanezt a feladatot. Nézzük tehát meg az egyik ,kó- 
sza" IP csomagot 8), hogy vajon mit tud magáról: 
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Microsoft 


Network Monitor 


(III. rész) 


IP: ID - 0x343D; Proto - ICMP; Len: 1500, Frag. 


3 Offset -— 1480 (0x5C8) 
IP: Total Length -— 1500 (0Ox5DC) ; £ 


IP: Identification - 13373 (0x343D) 
IP: Flags Summary - 201 (0xC9) 


IP: ....... 1 - More fragments in datagram 
4 after this one 
Bs. éssásésó 0. - May fragment datagram if 


4 necessary 
IP: Fragment Offset - 1480 (0x5C8) bytes 
IP: Time to Live -— 128 (0x80) 
IP: Protocol - ICMP - Internet Control Message 
IP: Fragmented Datagram Data: Number of data 
4 bytes remaining - 1480 (0x05C8) 6 


Elég sok újdonságot mutat ez a néhány, természetesen gon- 
dosan megritkított sor. Az IP fejléc Protocol mezőjéből leol- 
vasható A), hogy az itt szállított adat tulajdonképpen ICMP, 
vagyis annak maradéka. Honnan tudjuk, hogy maradék? Egy- 
felől onnan, hogy a Fragment bit 6) be van állítva, ami tu- 
lajdonképpen nem azt jelzi, hogy az éppen nagyítónk alá ke- 
rült csomag egy töredék, hanem azt, hogy további töredé- 
kek várhatók (More fragments in datagram after this one). 
Másfelől onnan, hogy a következő olvasható a ,hasznos" 
adatok előtt 8: Fragmented Datagram Data: Number of da- 
ta bytes remaining. 

Ami pedig a NetMon lustaságát illeti (hogy csak odafigyelés- 
sel deríthető ki, hogy ez a ping folytatása) érthető, hiszen 
ICMP fejlécet nem találunk ebben a csomagban. Minek is 
kellene mind a hét utazó csomagban megismételni, hogy ez 
egy ICMP Echo? A csomagok anélkül is utat találnak felfelé 
a protokollveremben. A kérdés csak az, hogyha a gép egy- 
szerre két nagydarab, töredezett pinget kap, akkor a töredé- 
keket hogyan tudja megfelelően osztályozni, hogy honnan 
jöttek? Erre szolgál az Identification (-13373 (0x343D)) 
mező (2. Minden beérkező IP csomagban, és töredékeiben 
azonos ez a random érték. Így nincs más teendője az IP fel- 
dolgozónak, mint mindaddig ugyanoda dobálni a beérkező 
töredékeket, amíg azok Identification mezője megegyezik, 
és be nem fut az utolsó töredék, ahol a Fragment bit már 
nulla (Last fragment in datagram). 


Tördelés 

Most vessünk egy pillantást a tördelés általános menetére. Az 
alábbi ábra a PING feldarabolásának sematikus vázlata. 
Összeáll a teljes, tízezer bájtos PING, és ezt valaki csomagok 
sorozatára bontja úgy, hogy az ICMP adattartalom lesz a tran- 
csírozás áldozata - de az IP fejléc épségben megismétlődik! 
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nHasznos" adat, 10000 bájt 


(  Feldarabolandó 10000-ICMP fejle [ 











Eth.] IP [ICMP  abcdefghijklmnoparstuvwabcdefghijklmnopa 
1514 bájt —— ,, 1480 , 1480 , ...még 3x1480 1120, 


5 A 10000 bájtos ICMP Echo darabolás előtt... 











1514 bájt 


abcdefgh 1472 


ijklmnopgrstuv 1480 
wabcdefghijklm 1480 
nopgrstuvwab 1480 
cdefghijklmno.. 1480 


parstuvwabcdef 1480 


ghijklmn 1128 
1514 bájt 
a ...és a darabolás után 


A teljes átvitt adatmennyiség a fejlécekkel együtt pedig 
6x1514-4-11162-10246 bájt, ami már az Ethernet és IP fejlécek 
méretét is tartalmazza. Ki végzi vajon a tördelést? Az előzőek 
alapján az IP protokollra gyanakodhatunk. Más alkalmazások- 
ra gondolva beláthatjuk, hogy nem az alkalmazás darabol. Az 
biztos, hogy nem az Excel fogja szorgosan felaprítani a FON- 
TOS.XLS-t adatátvitel előtt, hisz pontosan arra találták ki a 
rétegzett hálózatni architektúrákat, hogy például a hardver 
által okozott kellemetlenségek rejtve maradjanak a maga- 
sabb szintű rétegek, s főleg az alkalmazások elől. Jelen eset- 
ben az , alkalmazás" az ICMP, előle rejtve marad a darabolás. 
De vajon miért pont az IP végzi ezt a munkát? Miért nem az 
Ethernet meghajtóprogramja? Hisz mégiscsak közelebb áll az 
1514 bájtos korlátot okozó Ethernet kártyához? 

A kérdés jó, a válasz pedig az, hogy az Ethernet fejléc 
ugyan ,közelebb" van a hardverhez, de épp emiatt kevésbé 
számíthatunk rá: amikor egy IP csomag útválasztó-hegye- 
ken át jut el egy távoli kiszolgálóig, akkor az Ethernet fej- 
léc tartóssága enyhén szólva is megkérdőjelezhető, hisz a 
legelső útválasztó lebontja, és teljesen más (például Token- 
Ring) fejlécet illeszt a csomag elé. Így a végponttól vég- 
pontig történő címzés nem bízható az Ethernetre, csak egy 
minden matatást és útválasztást túlélő rétegre - s az IP 
pont erre való. Minden töredezett csomag elején ott a he- 
lye az IP fejlécnek, hogy a töredékek mindegyike utat ta- 
láljon a célba! Az ICMP fejlécről ugyanez a nagyfokú hasz- 
nosság már nem mondható el, emiatt az már a tördelés ál- 
dozatául esik. Ha majd rátérünk a TCP csatorna elemzésére, 
látni fogjuk, hogy ott már a TCP fejléc is beleszól a szállí- 
tásba, így világos, hogy az sem fog belekerülni a darálóba. 
A következő kérdés önként adódik: honnan tudja az IP, vagy 
majd a TCP, hogy mekkorára kell tördelni? A hálózati kártya ál- 
tal elfogadott legnagyobb keret méretét, valamint az összes ré- 
teg fejlécigényét megfelelő API hívásokkal le lehet kérdezni, s 
a Windows 2000 ezt éppúgy elvégzi menet közben, mint annyi 
minden mást. De hogy egy kicsit a múltba révedezzünk.. . 


Maximum Transmission Unit 

Hajdanában-danában, amikor az operációs rendszerek még 
feleennyit tudtak, bizony néha szükség lehetett a nem (iga- 
zán) támogatott kártyák 3rd party meghajtóit egy kis INI- 
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fájl matatással megsegíteni a hatékony működés érdeké- 
ben. Volt idő, amikor a tördelési határt kézzel kellett beál- 
lítani, s ennek a letűnt korszaknak állít emléket a regiszt- 
rációs adatbázis MTU kulcsa, ahol mind a mai napig meg le- 
het változtatni kézzel a tördelési határt. 


Kulcs neve: MTU, alapértelmezésben nincs ott 

Helye: HKLMISYSTEM(lCurrentControlSetlsServicestV 

4 TepiplParameterslInterfaceslcSinterface-names 

Adattípus: REG DWORD 

Tartomány: 0x44 — dinamikusan felismert MTU vagy 
OXFFFFFFFF 

Alapértelmezett érték, ha a kulcs hiányzik: 


OxFFFFFFFF (zAutodetect) 


Ennek a gyakorlatban még sohasem vettem hasznát, egysze- 
rűen csak érdekes. Még érdekesebb, hogy míg IP szinten a 
helyi hálózati kártya MTU-jára vagyunk kíváncsiak, addig a 
TCP réteg a két kommunikáló fél között a teljes útvonalon 
érvényesíthető MTU-ra kíváncsi, s ezt le is kérdezi az útvo- 
nal teljes hosszán - ha tudja. 


Protocol Coalesce Tool 

A széttöredezett PING remek lehetőséget nyújt egy másik na- 
gyon hasznos eszköz bemutatására, amellyel nemcsak a vég- 
ponti kommunikáló felek, hanem a hálózati forgalmat figye- 
lő köztes személy is képes a töredékeket egyesíteni, s ezzel 
értékesebb adatokhoz jutni. Sajnos az egyesítő (Coalesce) 
eszköz az ingyenes, beépített Network Monitorban le van 
tiltva, így csak vastagabb pénztárcájú olvasóim figyeljenek 
jól. A vagyonosabbak ugyanis egy szakajtóderéknyi kiváló 
szakértőt (Expert) is kapnak a NetMonnal, akik különféle 
elemzéseket végezhetnek a már elkapott/elmentett hálózati 
forgalom alapján. A Tools-sExperts menüpontból indulunk 
(figyelem, a NetMon menüi változnak annak függvényében, 
hogy melyik ablakban: a fő vagy a részletes nézetben ácsor- 
gunk éppen!) ahol elénk tárul egy csomó fura szerzet, ame- 
lyekkel részletesebben majd egy későbbi cikkben foglalko- 
zom, most a töredezett ping összevonására összpontosítunk. 


al 
Groupz 








An Expents 
DJ Average Servet Response Tne 
DJ Piopetty Ditrbution 


a 

DJ Pialocal Dietídutton 
EJ TCP Retransmi 
EJ TopUsers 














5 A Protocol Coalesce Tool 


A ,Protocol Coalesce Tool"-t az ,Add to Run..." gombbal 
áthajítottam a jobboldalra, a lefuttatandó feladatok közé, 
s a ,Run Experts" megnyomása után máris gyönyörködhe- 
tünk, no nem az eredményben, hanem abban az útvonal- 
ban, ahova a szakértés eredménye került, ami roppant szív- 
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derítő látvány, különösen, ha a Desktopra teszi ;) 


c:Wocuments and SettingsVfm.NETACADEMIAN 
4 Desktoplbigping(Coalesced)02.cap 


Innen már csak egy kis egérfutkosás, és megnyitható a kész- 
termék, az összevont pingek fájlja. Vessünk egy pillantást egy 
összevont ICMP Echo-ra. Mekkora az Ethernet keret mérete? 


KTB ZETET TETTETETT TT] 











4 2.974187 — 000001000000 FOR320000100 ICHP Rcho: From Z12.97.09.40 To 212—1] 


Acho Reply: To Z12.97.09.40 Fec 


sál 


s 2.72SZ4S — ROR320000100 000001000000  ICHP 








002700 7 6 69 EA 65 €C ED ék ép 70 91 72 73 94 95 76 gnljklmmopgrstuv 
j0002710 97 61 62 63 64 45 6 67 é6 659 EA EB EC ED EE EP vanedatyaljkisne 
e] — Ma 








5 Összevont bigping 


Amint az a fenti ábráról leolvasható, a keretméret 10042 bájt 
(8), ami sokszorosa a maximális 1514 bájtnak. Az összevonás 
eredménye többé soha nem tuszkolható ki az Ethernet hálózat- 
ba, bármennyire is szabványos keretnek látszik első pillantásra, 
s bármilyen csábító is a pénzes NetMon , Transmit Frame" me- 
nüpontja. Number of data bytes remaining? 10028-10000 betű 
420 bájt IP fejléc -- 8 bájt ICMP fejléc. Pont, mint azon az elő- 
ző ábrán, ahol a ping darabolás előtti állapotát rajzoltam le. 
Ugyanezzel az eszközzel lehet egy, akár megabájtos keretbe 
összeszedni a hálózati forgalomban tördelve utazó dokumentu- 
mokat. De nem akarok további hackertippeket adni, haladjunk a 
korral, és lássunk más érdekességeket az ICMP háza tájáról. 


Tracert 

Gondolkodott-e már valaki azon, hogy a tracert (Trace Rou- 
te) parancs honnan a csudából tudja két távoli végpont kö- 
zött az útvonalat? Talán le lehet kérdezni az útválszatókat? 
Lehet, hogy le lehet, de honnan tudjam, hogy melyiket, hisz 
az IP-ben éppen a szabad útválasztás az egyik legnagyobb 
találmány a világon, azaz akár minden egyes IP csomagom 
más útvonalon juthat el a célállomásig. Vajon van-e esély 
arra, hogy hálózati forgalmam nem a tracert által kiírt/meg- 
jósolt irányba fog menni? Ha alternatív útvonalak vannak a 
két végpont között, és az útválasztók útvonaltáblája is lehe- 
tővé teszi, akkor bizony jó esély van rá! Aki esetleg nem em- 
lékezne rá, a tracert így működik: 


c:VStracert www.netacademia.net 


Tracing route to ww.netacademia.net [212.97.8.36] 


over a maximum of 30 hops: 


1 — 510 ms 361 ms 260 ms 
4 as5200-O.ahol.com [212.97.9.1] 
2 — 351 ms 240 ms 221 ms 
4 core-if.routerO.hu.ahol.com [212.97.8.1] 
3 — 310 ms 240 ms 241 ms 


4 hofeherke.netacademia.net [212.97.8.36] 


Trace complete. 
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Sajnos túl közel ültem a webkiszolgálónkhoz, így a lista rö- 
vidre sikeredett, de a világ más tájairól a www.netacademi- 
a.net bizony akár 40 routernyi távolságban is lehet! A vá- 
laszban soronként láthatjuk a köztes útválasztókat, valamint 
azok (3 darab) válaszidejét. A válaszidők átlaga talán töb- 
bet mondana, de ez a jószág három különböző mérésének 
eredményét nem képes kiátlagolni, hanem szépen kiírja 
mindet egymás mellé. Például az as5200-O.ahol.com 
[212.97.9.1] nevű gép először 510 ms, másodszor 361 ms, 
végül a harmadik mérésre 260 ms alatt válaszolt. Ha a mért 
idők helyén csillagokat látunk, akkor az adott válaszidő több 
volt, mint 1 másodperc. 

Idejében elindított NetMonnal szerencsésen elkaptam a tra- 
cert hálózati forgalmát, hogy megvizsgálhassuk, vajon me- 
lyik az a protokoll, amivel routereket lehet lekérdezni. 
Igen, az ICMP-ről van szó már megint. Említettem, hogy az 
ICMP-nek rengeteg változata van, ezek közül most ismerked- 
jünk meg az Echoval... Na neeeeeeee! Már megint a ping? 
Igen, a ping fog segíteni, mert olyan érdekes módon fogjuk 
használni, hogy a router kénytelen lesz válaszolni, azért mert 
a csomag TTL-je - gonosz módon - még a célba jutás előtt 
lejár. A múltkori cikkben emlékeztem meg az IP fejléc mezői- 
ről, s akkor esett szó a TTL szerepéről, ami megakadályozza, 
hogy egy csomag a végtelenségig keringjen hibás útválasz- 
tású hálózatodon. Általában egy IP csomag elég magas TTL- 
lel indul útjára (128), ami elegendően nagy ahhoz, hogy a 
földet akár háromszor is körbeutazza. A tracert parancs azon- 
ban a legelső csomagot 1-es TTL-lel adja fel, amely az első 
útválasztón azonnal halálra ítéltetik. Mit tesz ilyenkor a rou- 
ter? Akár csendben el is temethetné a csomagot, de vissza- 
szól, mégpedig - és ez tényleg új ICMP szerep - ICMP Time Ex- 
ceeded üzenettel (időtúllépés). Ennek a válasznak a megfordu- 
lási idejéből számítódik és íródik ki a képernyőre a legelső vá- 
laszidő. Ezután a tracert még két ilyen TTL-1-es csomagot ki- 
küld, hogy meglegyen a három mérési érték, utána három da- 
rab TTL-2 küldése következik, majd TTL-3 és így tovább, amíg 
a TTL elég nagy nem lesz ahhoz, hogy a csomag eljusson a vég- 
állomásig, s az Echo-ra megérkezhessen az Echo Reply. Madár- 
távlatból a folyamat így néz ki: 






















3.80S926 — E69AZ0000100 000001000000 ICMP Tíne Exceeded: 212.97.8. az 
2.805926 — 000001000000 369AZ0000100 ICMP Echot Prom 212.97.09.60 To 
-166490 — EG9AZOOOO1OO 000001000000 ICMP Time Exceeded: 212.97.€.36 
4.166490 — 000001000000 ES9AZOOOOL10O ICMP From 212.97.09.60 To [ 
4.4Z6895 — EGJAZOOOOLOO 000001000000 ICMP Time Exceeded: 212.97.0.26 

5.178065 — 000001000000 E69AZO0OO100 ICMP Echo: From 212.97.09.60 To 
s 
s 





öganaong 


.SZ8611 — EG9AZ0000100 000001000000 ICMP Time Exceeded: 212.97.8.26 
-SZ8611 — 000001000000 369AZ0000100 ICHP Echo: From 212.97.09.60 To 
11 5.768986 — 369AZ0000100 000001000000 ICHP Time Exceeded: 212.97.8.36 
12 5.768966 — 000001000000 EG9AZOOOO100 ICHP Echo: From 212.97.09.60 To 
12 5.989229 — EG9AZOOOO100 000001000000 ICMP Time Exceeded: 212.97.0.36 
14 6.780561 — 000001000000 EGSAZOOOOI0O ICHP Echo: From 212.97.09.60 To 
1S 7.091045 — EG9AZO000100 000001000000 ICMP Echo Reply: To 212.97.09.60 
16 7.091045 — 000001000000 EGJAZODOOIOO ICMP Echo: From 212.37.09.60 To 
17 7.231419 — E69A20000100 000001000000 ICMP Echo Reply: To 212.97.09.60 
18 7.221419 — 000001000000 369AZ0000100 ICHP Echo: From 212.97.09.60 To 
19 7.571794 — XGSAZO000100 000001000000 ICHP Echo Reply: To 212.97.09.60 
20 0.000000 — 000000000000 000000000000 STATS Number of Frames Captured z 
2] 


(Network Monitor V5.00.646 Fz: 1720 Pf. 4 


o A tracert forgalma 
S most vizsgáljuk meg az egyes csomagokat! Vajon a feladott 


Echo-kban mi az IP cím? Mindig a legközelebbi routerre mu- 
tat? Szó sincs róla, mindig a végcél IP címe van benne, csak 
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a csomag (az alacsony TTL miatt) nem jut el a célba. A Time 
Exceeded csomag beltartalma, részenként a következő: 


IP: ID - Ox8214; Proto - ICMP; Len: 56 


IP: Precedence - Internetwork Control 


A Precedence értéke megváltozott Routine-ről (0x00) In- 
ternetwork Controlra (0xC0). 


IP: Data: Number of data bytes remaining -— 36 
(0x0024) 
ICMP: Time Exceeded: 212.97.8.36 (See frame 2) 
ICMP: Packet Type - Time Exceeded 
ICMP: Time Exceeded Code - Time To Live 
WExceeded In Transit 
ICMP: Data: Number of data bytes remaining - 


4 28 (0x001C) 


Innentől pedig megismétlődik az eredeti IP csomag, hogy 
az időtúllépési üzenetet fogadó oldalán fel lehessen ismer- 
ni, mi nem ért célba: 


ICMP: Description of original IP frame 
ICMP: (IP) Version - 4 (0x4) 


.. eredeti IP cím, checksum stb. 


A hibaüzenetet feladó gép IP címe alapján a feladó még el- 
végez egy fordított DNS lekérdezést (reverse lookup), hogy 
megtudja annak a routernek a DNS nevét (ha van), ahol a 
csomag elhunyt, majd kiírja a képernyőre. Az én esetemben 
a fordított lekérdezés azért nem látszik az elkapott hálóza- 
ti forgalomban, mert többször is lefuttattam ugyanazt a pa- 
rancsot, s míg legelőször még szükség volt a reverse 
lookupra (de akkor még nem futtattam a NetMont) , a továb- 
biakban már nem, mert a Windows 2000 ügyféloldali DNS 
gyorsítótára elmentette a válaszokat, amit IPCONFIG / 
DISPLAYDNS-sel le is ellenőrizhetünk. 

Egy kérdés maradt hátra: vajon biztosan a tracert által kiírt 
útvonalon fognak haladni csomagjaink? Mint az a madár- 
távlati képből látszott, itt egymástól teljesen független IP 
csomagok jöttek-mentek, az egyiknek kisebb volt a TTL-je, 
a másiknak nagyobb, de a feladó és a cél IP címén kívül 
más közös nem volt bennük. Ad abszurdum még az is elkép- 
zelhető, hogy minden egyes tracert csomag más úton jut el 
a számára kijelölt kivégzési pontig (ahol elfogy a TTL), így 
az útvonalinformációt - nagyobb távolságokon - igencsak 
fenntartásokkal illik kezelni. 


Pathping 

Ha valaki esetleg veszi a fáradságot és körülnéz a Windows 
2000 SYSTEM32 könyvtárában, talál ott egy pathping.exe 
parancsot, amely nagyjából ugyanazt tudja, mint a tracert 
azzal kiegészítve, hogy képes leellenőrizni az útvonal teljes 
hosszán az RSVP protokoll támogatását. Az RSVP a Resour- 
ce Reservation Protocol rövidítése, és garantált sávszéles- 
ség (005, szolgáltatásminőség) lefoglalására használható 
olyan útvonalakon, ahol minden router támogatja ezt a le- 
hetőséget. Csínján bánjunk a Pathpinggel, mert elég ala- 
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pos/erőszakos jószág! Míg a tracert beéri routerenként 3 
pinggel, addig ez utóbbi valóságos pingáradatot ereszt meg 
a célgép felé (routerenként 100 darab ICMP Echo!!), igaz, 
mérési eredményei jóval pontosabbak a tracert-től kapott 
adatoknál, hisz száz ping esetén már van mit statisztikáz- 
ni: százalékosan meg tudja mondani, melyik útválasztó 
mennyit hibázik. Az alábbi ábra azt mutatja, hogy milyen 
kiváló vonalaink vannak a Microsoft.com-ig ;) 


MAL] 








5 A pathping eredménye 


Ennek a mérésnek a hálózati forgalma 1000 (ezer!) darab ICMP 
Echo-t, és Replyt jelentett, erre bizonyíték az elkapott forga- 
lom utolsó , keretében", a statisztikacsomagban olvasható: 


STATS: Number of Frames Captured - 2048 
STATS: Elapsed Time - 5 Minutes 18 Seconds 

W 439786 MicroSeconds 

STATS: Total Frames Captured - 2048 (0x800) 
STATS: Total Bytes Captured - 262073 (Ox3FFB9) 
STATS: MAC Frames Received - 1875 

STATS: MAC CRC Errors - 0 

STATS: MAC Bytes Received - 0x000000000009C€036 
STATS: MAC Frames Dropped due to No Buffers - 0 
STATS: MAC MultiCasts Received -— 30 

STATS: MAC BroadCasts Received - 26 

STATS: MAC Frames Dropped due to HardWare 


4 Errors 5 0 


A statisztikacsomagot mindig a NetMon Trace utolsó csomag- 
jában, az itt felhasznált fájlokat (BIGPING.CAP, tracert.cap, 
pathping.cap) pedig a weben találják Lelkes Olvasóim. 


Fóti Marcell 
marcellfonetacademia.net 
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Közeleg az idő, amikor PC-ink hátuljáról eltűnnek a soros és 
a párhuzamos portok csatlakozói, megszűnik a kábeláradat. 
Nem lesz PS/2-es port, nem lesz külön hangkártya- és mo- 
demkimenet, nem fog fájni a fejünk az elfogyott IRO-k 
miatt. Lesz viszont egy vagy két (néhol négy) USB konnek- 
tor, egy IEEE-1394 csatlakozó, egy monitorcsatlakozó és 
egy helyi hálózati kimenet. Semmi több. 


Mi is az a(z) USB? 

Mint a neve is mutatja az USB (Universal Serial Bus) egy 
busz, melyre maximum 126 (!) eszköz csatlakoztatható. Fi- 
gyelem, ezek az eszközök összesen egyetlen egy megszakí- 
tási címet fognak elhasználni! Az eszközök bármikor csatla- 
koztathatók vagy leköthetők a buszra(-ról), az operációs 
rendszer automatikusan érzékeli és , beállítja" ezeket. Nincs 
jumperelés, nincs újraindítás, minden Plug and Play. 


Hogyan kell használni? 

Kábelezési szabályok: A kábelek legfeljebb 5 méter 
hosszúak lehetnek, melyek segítségével maximum egy 5 ká- 
belből álló láncolatot hozhatunk létre a számítógéptől a 
legutolsó még használható eszközig. (Tehát a maximális tá- 
volság a géptől 25 m, de a kábelhosszokat hiába vesszük ki- 
sebbre, a láncolat akkor is csak öt lépésből állhat.) A csomó- 
pontokban természetesen lehetnek elágazások, ha az esz- 
közök több USB porttal rendelkeznek vagy az eszköz maga 
egy USB HUB. (Így lehetséges az elméleti 126-os határ eléré- 
se.) Az alap USB kábelnek különböző a két vége, ezért le- 
hetetlen nem működő , hurkot" létrehozni. 
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o Az ábrán jól látható a maximum 5 láncszem 
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Használjunk 
USB-t 
és 1394-et 


Portok? 

Egy USB port lehet aktív vagy passzív. Az aktív port maga biz- 
tosítja a rácsatlakoztatott eszköz számára az energiát (aktív 
portja természetesen olyan eszköznek lehet, amely az áramot 
nem a buszról veszi). A buszt vezérlő szoftver gondoskodik ar- 
ról, hogy ha , elfogyott a buszról az összes energia" (maximum 
500 mA) akkor több eszköz ne akarjon áramot felvenni. 


1 General Network Idertécaten . Hardware ] User Picfies ]/ddocncsá] 
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5 Az egérkénk passzív és sokat fogyaszt, a nyomtató vi- 
szont aktívan szerénykedik 


Ennek feloldására való az aktív port. Ha egy aktív portot tar- 
talmazó eszközt kikapcsolunk, akkor onnantól lefelé a lánc- 
ban lévő eszközök nem biztos, hogy működni fognak, minden 
az energiafelvételen múlik. Honnan tudhatjuk, hogy egy esz- 
köz mennyi energiát használ (lásd fent) vagy milyen sebes- 
séggel működik (high/low)? Erre szolgál a Windows 98 CD-n 
egy kis programocska: (Mtoolsveskitidiagnosetusbview.exe). 
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5 Az USBVIEW Windows 2000 alatt is megy... 








Az USB a következő operációs rendszerekben támogatott: 
Windows 95 0OSR2.1B; Windows 98; Windows 2000. 

És ha öregecske a gép? 

USB porttal nem rendelkező számítógépet ( pl. régebbi Pen- 
tium modellek) is bővíthetünk olyan PCI-os kártyával, amely 
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USB csatolót tartalmaz. USB segítségével akár hálózatot is 
kiépíthetünk, erre is léteznek már eszközök. 
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0 Az 1.1-es USB teljes sávszélessége hamar elfogyhat 


USB 2.0 

Az USB 2.0-s verziójában (melyet olyan cégek dolgoztak ki, 
mint a Compag, HP, Intel, Lucent, Microsoft, NEC és a Phi- 
lips) a sebesség közel negyvenszeresére, azaz 480 Mbit/s- 
ra emelkedik majd! Jó hír, hogy a gyorsabb adatforgalom 
a ,régi" USB kábeleken zajlik, valamint a meglévő eszkö- 
zök is ráköthetőek az új buszra (ez alól kivételek a HUB-ok, 
amelyek szerepét a már háromféle sebességre képes - 480, 
12, 1,5 Mbit/s - 2.0-sok veszik át). Ami viszont szükséges: 
egy USB 2.0-s PCI csatolókártya, vagy egy új alaplap, ami 
már 2.0-s USB-t támogat, de sajnos ezek megjelenésére 
még várnunk kell egy pár hónapot. (Az Intel már az 1815- 
ös chipsetben ígérte a támogatást, de később ez elhalasztó- 
dott.) A szoftveres támogatásra is várni kell, jelenleg még 
nem létezik 2.0-s USB patch a windows-okhoz. (A Whistler, 
akarom mondani" a Windows XP már támogatni fogja.) 


Technológia Maximális sebesség (elméletben) 
Soros port 230 kbit/s 

USB 1.1 Low 1,5 Mbit/s 

USB 1.1 High 12 Mbit/s 

FireWire 400 Mbit/s 

USB 2.0 High 480 Mbit/s 

Ultra SCSI-3 160 Mbyte/s 


Fire-Wire 

Mivel az USB 2.0 még nem elérhető, egy lehetséges alter- 
natíva lehet az IEEE 1394. Ez tulajdonképpen az Apple ál- 
tal kitalált Fire-Wire, amelynek szabványát 1990-ben kibő- 
vítették, s ennek eredményeképpen jött létre az IEEE 1394 
specifikáció. 


Sebesség 

A 1394-es busz két sebességen működhet: 200 Mbit/s-on 
(5200) és 400 Mbit/s-on (5400), ez utóbbi már 50 Mbyte/s-ot 
jelent. (Jobb, mint egy UW SCSI!) A nagy adatátviteli se- 
besség igénye főleg multimédiás applikációknál jelentke- 
zik, tehát azon eszközök lesznek (vannak) 1394-es csatla- 
kozóval ellátva, amelyek ebben szerepet játszanak: camcor- 
derek, videofelvevők, merevlemezek. Persze jelenleg is lé- 
teznek olyan eszközök (pl. videograbber kártyák) , melyekkel 
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mondjuk a videófeldogozás elvégezhető, de az 1394 jóval 
olcsóbb megoldást jelent. 

Az 1394 segítségével könnyedén létrehozhatunk otthon is 
egy kis videóstúdiót, hiszen az 1394-es buszra csatlakoztatott 
videókamera és a merevlemez között közvetlen adatforgalom 
jön létre, a , film" egy szoftverrel megszerkeszthető, majd tá- 
rolható az ugyancsak a buszra csatlakozható videofelvevőn. 


Camcorder 


PC 1394-es 
busszal 





Video recorder 
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5 Az én kis házistúdióm... 




















Kábelezés 

Az IEEE 1394-es buszra maximum 63 eszköz csatlakoztatha- 
tó egyszerre, a maximális kábelhossz (két eszköz között) 
négy és fél méter lehet. Legfeljebb 16 ilyen kábel fűzhető 
láncba, tehát a számítógép és a legmesszebb lévő eszköz ma- 
ximális távolsága 72 méter. Nincs szükség terminálásra, ID 
jumperelésre (SCSI), az eszközök menet közben csatlakoztat- 
hatók vagy leköthetők (hot plug), minden rákapcsolt eszköz 
automatikusan címződik. Csakúgy, mint az USB esetében, a 
csillagpontos elrendezéshez HUB-okat használhatunk, de 
minden olyan eszköz, amelynek egynél több 1394-es csatla- 
kozója van már HUB-ként is funkcionál. Az eszközök áramfel- 
vétele is hasonló az USB-nél látottakhoz, azaz vannak aktív 
és passzív portok. A passzív porttal ellátott eszköz közvetle- 
nül a buszról veszi fel a működéséhez szükséges energiát, az 
aktív port pedig a passzív eszközöket tudja ellátni maximum 
3 Watt energiával. A használt kábel 6 eres: 2 kell az ,áram- 
hoz", 2 kábelen megy az adat, kettőn pedig a szinkronjel. 
(Erről többet itt most inkább nem írnék...) 


Csatlakozó 

A megfelelő csatlakozó keresésekor a következő szempon- 
tokat vették figyelembe: legyen strapabíró, legyen megfele- 
lően árnyékolt és persze olcsó! A választás a Nintendo Ga- 
meboy csatlakozójára esett... 

Azoknak sem kell elkeseredniük, akiknek a gépén nincs 
1394-es csatlakozó, hiszen vásárolható olyan kártya (álta- 
lában PCI buszos), amely rendelkezik ilyennel. 

Végezetül csak érdekességként jegyzem meg, hogy az 
SCSI-3 specifikáció felveti az IEEE 1394 kábelek használa- 
tának alkalmazását is (hiszen ez jóval olcsóbb). 7 


Tóth László 
toth omontana.hu 
MCSE, Compag ASE 
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A Windows NT 


. . és a Windows 2000 
memóriakezelése 


avagy 


What is the Matrix? 

Sokszor elhangzó kérdés, hogy ha egy hálózatban X számú 
felhasználó van, Y darab megosztott könyvtárban dolgoz- 
nak Z darab fájllal, akkor mennyi RAM kell a Windows 
NT/SBS/2000 kiszolgálóba. Sajnos erre a kérdésre a Micro- 
soft modern operációs rendszerei esetén nincs egyértelmű 
válasz, mert a virtuális memóriakezelés virtualizálja a fogal- 
makat is. Mit tekinthetünk foglalt memóriának? Mi a sza- 
bad? Mikor kell lapozni? Ezekre sincs egyértelmű válasz: 
tiszta Matrix az egész. Amikor Neo megkérdezi, hogy a va- 
lóságot látja-e, Morpheus így válaszol: , What is real?" 

A valóság megismeréséhez kemény tanuláson kell átesni. Az 
alábbi cikk nem felületes olvasmány, akinek nem megy el- 
sőre, olvassa át mégegyszer! Ha kérdései vannak akkor pe- 
dig írjon a Windows 2000 listára. Vitassuk meg! 


Mit is jelent a virtuális memóriakezelés? 

How do you define real? 

Különösen fájó ez a gumivalóság, ha hardverbővítésnél kell oko- 
sat mondani, bár napjaink RAM árai mellett már könnyű benyög- 
ni a gigát - úgysem okoz gondot a kifizetése. Ennek ellenére úgy 
gondolom, érdemes megismerkedni a memóriafoglalás rejtel- 
meivel, mert teljesítménytuningoláskor nem árt a tisztánlátás! 
Kezdjük a virtuális memóriakezeléssel (VM): áldás, vagy átok? 
Sokak számára ez a fogalom az állandóan zörgő merevlemez- 
zel és a lassan vánszorgó rendszerrel azonos, legszívesebben 
kikapcsolnák - ha lehetne. Mindazok, akik a VM kikapcsolásá- 
val próbálkoznak, vasvillával hányják a diót a padlásra. A Win- 
dows XP-ben meg lehet szabadulni a lapozófájltól - de ez nem 
egyenértékű a VM kikapcsolásával. Aki komolyan gondolja, 
hogy neki nem kell VM, az telepítsen egy Windows 3.1-et, és 
a WIN.COM-ot mindig /r (real) kapcsolóval indítsa! 
Valójában a VM sokkal több előnnyel, mint nyűggel jár, nem 
csoda, hogy lassanként a konkurensek (Novell Netware, 
Apple Macintosh) is elérkeznek ide. Az sem igaz, hogy a VM 
egyet jelentene a lapozófájl zörgetésével, bár ha kevés a 
RAM, bizony előfordul ilyesmi. A VM alapvetően az Intel (és 
más gyártók) processzorainak hardverlehetősége arra, hogy 
az alkalmazások elől elrejthető legyen a párhuzamosan fu- 
tó több száz végrehajtási szál egymástól elkülönített me- 
móriaterületeinek borzalmasan bonyolult kezelése és védel- 
me. Ha kikapcsolható lenne a Windowsban a VM, megszűn- 
nének a védett memóriaterületek, és a rendszer stabilitása 
is! (Egyik Macintosh-használó ismerősöm csodálkozott rá a 
múltkor, hogy a Windows alatt van Task Manager, s hogy ha 
egy alkalmazás lefagy, attól még nem kell újraindítani a gé- 
pet. A Mac a mai napig nem tart itt!) 

A hardveres alaplehetőségre épít, és azt bonyolítja tovább a 
Windows, amikor kihasználja, hogy ha olyan memóriaterü- 
letre bökünk a címtérben, amely mögött nincs fizikai RAM, 
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akkor a gép nem lefagy, hanem ún. Page Fault megszakítást 
kezdeményez. A megszakításkezelő rutin pedig bepótolhatja 
a hiányzó memóriát, és utasíthatja a processzort, hogy tér- 
jen vissza a félbehagyott műveletre. A Windows esetében a 
memórialapok mérete egységesen 4 kilobájt, ami némi lapo- 
zási pazarlással jár, ha csak 3 k-t kellene belapozni, de bu- 
sásan megtérül abban, hogy a lapozófájl kezelése sokkal 
egyszerűbb: nem kell változó hosszúságú blokkoknak helyet 
keresni, nem kell töredék helyeket egybenöveszteni - egy- 
szóval nincs szükség szemétgyűjtésre (Garbage Collection). 
Először 1997-ben dühödtem be a VM működésének érthetet- 
lenségén. A rendszer megfigyelésével néhány olyan gondolat 
merült fel bennem, mely végül elvezetett a memóriakezelés 
megismeréséhez. Ezt követően került kezembe az Inside Win- 
dows NT egyik kiadása, melyben meglepve olvastam korábbi 
natív spekulációim igazolását. Az i-re a pontot pedig David 
Solomon mostani Tech.Ed előadása tette fel: tiszta a kép! 


Az első apró jelek 

Like a splinter in my mind that drives me mad 

Először gyakorló rendszergazdaként vettem észre, hogy va- 
lami nem stimmel a világgal. Volt egy hálózatom több száz 
olyan munkaállomással, melyeknek merevlemezére az Office 
egyszerűen nem fért fel. Mit tesz ilyenkor a rendszergazda? 
Elolvassa a dokumentációt, és felfedezi, a SETUP.EXE /A 
módszert, mellyel az Office hálózatos telepítésére is lehe- 
tőség nyílik. S fut a WINWORD.EXE a hálózati megosztásról, 
mint a kisangyal - de meddig? 

A kiszolgálók néha-néha lepihennek, ha nagyon fáradtak. 
(Nem, a Linux az nem. Meg a NetWare sem. S ha már itt tar- 
tunk: a Windows sem. Akkor biztos ZX Spektrum kiszolgálóim . 
voltak. Ki emlékszik erre ma már?) Egy szó mint száz, az a 
VALAMILYEN kiszolgáló, amiről a Word futott, néha lepi- 
hent. Mit gondolnak, milyen közvetlen hatással volt ez a 
több száz felhasználóra? Döbbenetes módon 
SEMMILYEN 

hatással sem! Piri és Rozi zavartalanul csépelte tovább a 
Wordöt. Ez nem csoda - gondoltam - hisz a gépek leszedték 
a hálózati megosztásról az egész WINWORD.EXE-t a lapozó- 
fáljba (pagefile.sys). Egy pár perc múlva azonban szóltam 
Pirinek, hogy jobb lesz, ha mégis elmenti a művét, mert a 
kiszolgáló öt perce leállt. És abban a pillanatban, hogy a 
mentésre kattintott, a Word úgy elszállt, hogy öröm volt 
nézni. Piri is örült, s ennek egy cifra káromkodással adott 
hangot. Bár nem értettem a jelenséget, a zavartalanul dol- 
gozó Rozihoz új stratégiát agyaltam ki: neki azt mondtam, 
tegye vágólapra a művét. És csodák csodája, az akció sike- 
rült, a Word még elbillegett egy darabig, majd ugyanúgy ki- 
nyiffant, mint Pirinél, de a doksi megvárt minket a vágóla- 
pon. Mi a két eset között a különbség? Egyáltalán miért 
esett el a Word, ha egyszer bekerült a helyi Windows lapo- 
zófájljába? Hát, mert nem került bele. 
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Sok-sok kísérletezés után rájöttem arra, amit kapásból tud- 
nom kellett volna: nem az egész WINWORD.EXE lapozódik 
ki, hanem csak az adatszegmensei! A kódszegmenseket fe- 
lesleges lapozófájlba tenni, hisz tökéletesen visszaállítható 
állapotban megtalálható valahol máshol: a megosztott 
könyvtárban a kiszolgálón! A Word addig képes futni, amíg 
képes pótolni a hiányzó EXE-falatkákat az eredeti fájlból. 

Tehát a lapozás, és a lapozófájl csörgése nem sok összefüg- 
gést mutat a programok kódszegmenseinek használatával. 
Ha kevés a memória, a Windows igen hatékonyan , lapozza 
ki" a kódszegmensek tartalmát: egyszerűen eldobja! Az 
alábbi ábra ízelítőt ad a valóságról, s leolvasható róla a fu- 
tó WINWORD.EXE memóriadarabkáinak kilapozási útvonala. 


RAM terület 





PAGEFILE.SYS 


5 Egy alkalmazás kilapozása memóriahiány esetén. A 
szürke négyzetek a fizikai memóriában vannak — a töb- 
bi terület nincs ott! 


A kódszegmensek elpárolognak, míg az adatszegmensek és 
a heap memóriablokkok (FONTOS.DOC) valóban a lapozó- 
fájlba kerülnek. 


Egy pár szó a Task Managerről 

All Im offering is the truth. Nothing more. 

Próbáljuk megállapítani az előbb emlegetett alkalmazás, a 
WINWORD.EXE összesített memóriafoglalását! Elsődleges me- 
móriaméricskélő eszközünk a Task Manager, a szokásos, alap- 
számlálókon kívül további memóriamennyiségek mérésére is 
képes. Az alábbi ábra bemutatja, milyen sokféle mennyiséget 
jeleníthetünk meg akár ezzel az egyszerű eszközzel is. 
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Ha megjelenítjük mind a Memory Usage, mind pedig a Vir- 
tual Memory Size oszlopokat, érdekes felfedezést tehetünk: 
a két számoszlop között nem sok összefüggés mutatkozik, 
hol az egyik a nagyobb, hol a másik. Az alapnézetben is 
látható Mem Usage az alkalmazásnak juttatott fincsi fizi- 
kai memória, míg a VM Size az alkalmazás pagefile.sys-be 
kilapozott része. Ha pontosan tudni akarjuk az alkalmazás 
memóriaéhségét, fejben gyorsan összeadjuk a kettőt, s 
megkapjuk azt a számot - melynek semmi köze semmihez... 
Ez azért van így, mert a korábbi, kilapozós ábra tanúsága 
szerint a végrehajtható kódrészek (a kódszegmensek) nem 
kerülnek ki a pagefile.sys-be, hanem ,elpárolognak"! 
Falba ütköztünk: nem vagyunk képesek megmondani egy 
alkalmazás összesített memóriaigényét - legalábbis a Task 
Manager nem segít ebben. 

Térjünk át a sokkal kifinomultabb Performance Monitorra 
(Windows 2000-ben System Monitor)! 


A Performance Monitor segítsége 

You mean I can dodge bullets? 

Első lépésként egyeztessük óráinkat, azaz állapítsuk meg, hogy 
az alábbi, Report nézetben használt PerfMon milyen számláló- 
kat mutat a kiválasztott Process objektumon, s ezek vajon 
megegyeznek-e a Task Manager valamelyik számlálójával. 
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Process WINWORD 
Page Faults/sec 0.000 
Page File Bytes 7143424.000 
Pool Nonpaged Bytes 11216.000 
Pool Paged Bytes 94200.000 
Private Bytes 7143424.000 

124260352.000 
Working Set 20458192.000 


B j KEGE —j——— 


5 Mit mond a Performance Monitor a WINWORD.EXE-ről? 
Rövid számológép-sanyargatás után rájövünk, hogy ami: 


...-a PerfMonnál.. ] a Task Managerben... 





Page File Bytes  ] WM Size 





Working Set I MEM Usage 


Így csak öt eddig nem említett számláló maradt. Ezek kö- 
zül három megjeleníthető a Task Managerben, de nem sok 
segítséget nyújtanak: 

8 A Pool Paged Bytes az a kilapozható memóriamennyiség, 
melyet az alkalmazás részére a kernelben tart fogva az 
operációs rendszer (ablakkezelők (hWND) stb.) 

"8 A Pool Nonpaged Bytes az a NEM lapozható memória- 
mennyiség, melyet szintén az alkalmazás részére a ker- 
nel foglalt nekünk c 

"6 A Page Faults/sec a másodpercenkénti ki-be lapozások 
mérőszáma 

Ismeretlenként tehát itt maradt a Private Bytes és a Virtu- 

al Bytes. Hátha ezek választ adnak a kérdésre: mennyit fo- 

gyaszt a WINWORD.EXE? 
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"8 A Private Bytes azon memóriamennyiség, mely az alkalma- 
zás védett területén van, más processz nem férhet hoz- 
zá kívülről 

"8 A Virtual Bytes pedig az alkalmazás által kért összes me- 
mória mennyisége 

Hopp! Úgy tűnik, helyben vagyunk! A Virtual Bytes megvá- 

laszolja a kérdésünket! Lássuk csak: 140951552 bájt, ami 

annyi mint 134,42 megabájt. Uramisten! Csak nem kap 
ennyit egy nyavalyás word? 


Konklúzió 

Welcome to the real world! 

Az élet szép, de a helyzet szomorú. A Virtual Bytes szépen 
megmutatja, hogy az adott alkalmazás mennyi memóriát 
KÉRT, de azt sajnos nem, hogy mennyit KAPOTT! (Ez utób- 
bi lenne a Committed Bytes, lásd később.) De legalább tet- 
ten érhető a virtuális memóriakezelés egyik igen jelentős 
előnye: az alkalmazások memóriaigénye akkor kerül kiszol- 
gálásra, ha az általuk , lefoglalt" területre valóban szüksé- 
gük lesz, oda írni, vagy onnan olvasni akarnak (Demand Pa- 
ged Virtual Memory). Ilyenkor Page Fault (laphiány) meg- 
szakítás keletkezik, s az operációs rendszer gyorsan odadob 
egy adag memóriát, hadd higgye azt a Word, hogy megka- 
pott mindent, amit kért! 


FONTOS! 

Valójában minden processz 0 (nulla) méretű Working 
Settel indul. Az alkalmazás mintegy , befaultolja", ,,be- 
hibázza" magát a memóriába, mert kezdetben nem kap 
egy fikarcnyi RAM-ot sem (kivéve az EXE legelejét), és 
ahogy futni kezd, csapkod ide-oda, mindannyiszor üres 
lapot talál, amit a VM kezelő bepótol neki! 


Ez a Windows 2000-nél még elég bután megy, mert - bár 
minden egyes alkalmazás mindig ugyanúgy indul - a 2000 
nem adja neki oda az indulólapokat, az EXE lassan , befaul- 
tolódik". Ez magyarázza, hogy például egy vacak kis CALC- 
.EXE közvetlenül indítás után miért mutat 334 Page Faultot, 
pedig senki sem bántotta! 

A Windows XP-n gyorsabban fognak indulni az alkalmazá- 
sok, mert meg fogja tanulni az induláskor szükséges lapo- 
kat, leteszi egy .PF (PreFetch) fájlba, és második indulásnál 
már egy használható készletet tesz RAM-ba; nem nulláról 
kell bemásznia szegény alkalmazásnak. 


A lapozásról 

How deep the rabbit hole is? 

A Process objektum számlálóival tehát nem jutottunk a dolog 
végére. Nem tudjuk, hogy egy adott pillanatban mennyit fo- 
gyaszt egy alkalmazás, sőt, azt sem tudjuk pontosan, miért 
nem tudjuk, amit nem tudunk. Térjünk át most a Memory ob- 
jektum számlálóira, hátha így közelebb jutunk a működés lé- 
nyegéhez. Itt van mindjárt az Available Bytes és a Cache By- 
tes számláló. Ha egy gépet terhelésnek teszünk ki, ez a két 
számláló gyönyörű szimmetrikus ábrákat rajzol a képernyőre. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
LINUX KÜLÖNSZÁM 


A WINDOWS NT ÉS A WINDOWS 2000 MEMÓRIAKEZELÉSE 





JÉG cordis Windon  Hep JO égi m [oli 
] ádion ven  Exvortes [[£ 2 [Eliel e 
JESdösztst CD] arr elfele] lel lel] fe slel 

[I Console Root E ESESS ESB ZEYSEEZET SE PEE N ET TE SEN T SZ. HEZSSZZE ESET 


Új Syster Monitor 
1- őő] Performance togs a 

















Last 25747458  Averoge 24272036 Minimum 23031608 
Maximum 77426816  Duraton 140 








5 Available Bytes és Cache Bytes a PerfMonban 


Mintha látszólag minden bájt, mely lefoglalódik, a cache 
területre kerülne, és fordítva. Mintha soha semmi nem ke- 
rülne át például a programok hatáskörébe. (Persze átkerül, 
ha indítgatunk és leállítgatunk programocskákat, de ha csak 
a meglévőkkel manipulálunk, ez ritkán látszik.) Mi valójában 
az ,Available Bytes"? És mi a , Cache Bytes"? 


Kövesd a fehér rabbit 

Az operációs rendszer futása közben állandóan zajlik a lapo- 
zás. Ennek oka, hogy minden processznek korlátos a Wor- 
king Set mérete, s még rengeteg fizikai memória esetén is 
előbb-utóbb utoléri a végzet: bizonyos lapokról le kell mon- 
dania. Azonban ettől még nem fog zörögni a merevlemez. 
Ugyanis a Working Setből (LRU algoritmussal) kilapozott 
blokkok általában nem a merevlemezre lapozódnak, hanem 
előbb az úgynevezett Standby (rendelkezésre állási) memó- 
rialistára kerülnek. A Standby területen a memóriablokkok 
változtatás nélkül tárolódnak, hátha az LRU tévedett, és ha- 
marosan ismét szükség lesz rájuk, így innen a Working Set- 
ből kilapozott blokkok mindenféle merevlemez-tekerés nél- 
kül visszalapozhatók. A memóriából memóriába történő la- 
pozást Soft Page Faultnak hívjuk, ellentétben a valóban la- 
pozófájlművelettel járó Hard Page Faulttal. 


A Task Manager és a PerfMon-: Process objektum nem ké- 
pes különbséget tenni a Hard és a Soft Page Fault között, 
így azok a számlálók gyakorlatilag használhatatlanok a 
lapozófájlhasználat felbecsülésére! Egyedül a PerfMon- 
:Memória objektum ad valós képet a Pages/sec számláló- 
val, mert az csak a Hard Page Faultot méri 


A Standby listán kívül további memórialistái is vannak az 


operációs rendszernek, amint az az alábbi, David Solomon- 
tól lopott ábrán látható: 
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5 A Windows memórialistái 


A Working Setből a 4 kilobájtos lapok annak megfelelően 
szorulnak ki vagy a Standby Listre, vagy a Modified Page 
Listre, hogy tartalmuk módosult-e - azaz kód, vagy adat- 
szegmensről van-e szó. Ha egy alkalmazásból kilépünk, an- 
nak összes memórialapja a Free Page Listre kerül, felszaba- 
dul. Biztonsági okokból a Free listáról kizárólag olyan pro- 
cessz kaphat lapot, akinek amúgy joga lenne az adott lap 
olvasásához. Mivel azonban a kilapozott blokkban jelsza- 
vak, RSA kulcsok és egyéb érzékeny adatok lehetnek, a la- 
pok törlésen esnek át, mielőtt akármelyik processz kaphat- 
na belőlük. Így kerülnek át lenullázva a Zero Page Listre. 
Ha a szabad memória mennyiségére vagyunk kíváncsiak, 
nehéz helyzetben vagyunk, mert míg a Zero Page List nyil- 
ván szabad memória, addig a Free és a Standby így is, úgy 
is értelmezhető: ha visszalapozzuk eredeti helyére, akkor 
inkább , cache", ha viszont újra kiadjuk, akkor szabad... 
A Task Manager és a PerfMon által mutatott Avaliable By- 
tes (a fenti gyönyörű diagramon az alsó vonal) valójában a 
Free, a Standby és a Zeroed listákon lévő memóriablokkok 
összes területe! 

Már csak egyetlen dolgot kell megválaszolnunk: mi a Cache 
Bytes? 


Cache Bytes 

There is no spoon 

A PerfMon szerint: ,Cache Bytes is the sum of the System 
Cache Resident Bytes, System Driver Resident Bytes, System 
Code Resident Bytes, and Pool Paged Resident Bytes counters." 
Vagyis mindenféle System vicik-vacak által elfoglalt me- 
móriaterületek összessége! 

Ennek magyarázata a következő: nincs is olyan memóriatí- 
pus a Windowsban, hogy cache, mert a fenti listák gyakor- 
latilag elvégzik a gyorstárazást. Cache mechanizmus persze 
van: a Read Ahead, Lazy Write és a többi jól ismert algorit- 
mus itt is megvan, de nem egy különálló cahce manager- 
ben, hanem a VM memóriakezelés részeként. A trükk a kö- 
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vetkező: ha egy alkalmazás beolvas egy nagy fájlt, akkor a 
Read Ahead nem a hívó processz memóriaterébe dobálja az 
előrefutó olvasás eredményét, hanem az operációs rendszer 
saját Working Setjébe, hogy ha esetleg rosszul , gondolko- 
dott", és a Read Ahead eredménye mégsem kell az alkalma- 
zásnak, ne kelljen külön eltávolítania az alkalmazás memó- 
riateréből a kéretlen cuccot. E tény ismeretében érthető, 
hogy a Task Manager által mutatott Cache Bytes mást tar- 
talmaz NT4 és Windows 2000 esetén - hisz egyiknek sincs 
semmi köze a valósághoz. A , File Cache": 

0 NTA4 esetén valójában a system working set mérete (paged 
pool 4- NtosKrnl.Exe, az eszközmeghajtók kód- és adat- 
szegmensei stb.) Semmi köze semmihez! 

"B Windows 2000 esetén az NT4-es zagyvaság, plusz a 
Standby List mérete. 

A fura az, hogy a Standby List mérete beleszámítódik az 

Available Bytes-be is! Az Available és a Cache tehát sziámi 

ikrek, melyek a Standby Listnél fogva össze vannak nőve :) 


8 Windows Task Manager Hz zJOj2! 






































Totas—————————. f-Physical Memory (K) 

Handles 7987 [stat 126448 
Threads 393 (7 Avallable 7348 
Processes 42 [5 System Cache 31032 ] 
Commit Charge (£)———— r Kernel Memory (K) ii 
Total 186656 ) / Total 44636 [ [] 
Limit 294300 ) ) Paged 39412 [ [/ 
Peak 194408 ]) ] Nonpaged szz4 ] [] 


fProcesses: 42 ÍCPUUsage: 1996 [Mem Usage: 186656K / 294300K 7 





o A Task Manager buta arca. A dupla kurzor a sziámi 
számlálókat mutatja 


A Commit Charge pedig a lapozófájl méretéről ad közelítő- 
leges információt: A Memory-:Committed Bytes számláló 
ugyanis azt a mennyiséget mutatja, amennyit a Windows a 
kért memóriából valóban kiosztott, s melynek számára a 
lapozófájlban fészket is rakott, hogy ha majd kilapozódik, 
ne kelljen helykeresgéléssel bajlódnia. Milyen kár, hogy a 
Committed Bytes csak a Memory objektumon mérhető, s a 
processzeken nem! 


Fóti Marcell 
marcellf(-onetacademia.net 
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Emlékszem, pár évvel ezelőtt az útválasztás nemigen oko- 
zott fejtörést az IT szakemberek többségének: a hálózatok 
összekapcsolása (ha voltak egyáltalán hálózatok!) még 
nagyvállalatoknál is ritkaságszámba ment, s Internetkap- 
csolata sem volt senkinek. Nem túlzok: senkinek! De elmúl- 
tak már azok a boldog békeidők, amikor hálózat alatt egy 
másfél méteres koax kábelt, két T dugót és két lezáró el- 
lenállást értettünk, s annak is vége, hogy ,majd a Novell 
két kártyával elintézi", hisz az IPX protokoll is kihalóban 
van. Nézzünk szembe a tényekkel: a hálózatok rohamos bur- 
jánzása következtében a rendszergazdák folyamatosan fog- 
lalkoznak a problémával, s heti gyakorisággal kerülnek dön- 
téshelyzetbe: kell-e új subnet? S ha igen, milyen IP tarto- 
mányt kapjon? Mi fogja összekötni az új alhálózatot a régi- 
vel? Egy router? Milyen gyártmány? Milyen routing proto- 
kollt kell ismernie? Mennyibe kerül? 

Minden döntési helyzetben célszerű legelőször megvizsgál- 
nunk a szerszámosládát, hátha már birtokunkban van az a 
szerszám, amire éppen szükség van. Az RRAS szerszámoslá- 
dája igen gazdag. Nem mindenki tudja talán, de egy közép- 
kategóriás hardver útválasztót meghazudtoló funkciógaz- 
dagságú és teljesítményű eszköz van a birtokunkban! Is- 
merkedjünk meg a használatával, hátha beválik. A ládafia 
átkutatása előtt azonban ismerkedjünk meg az IP útválasz- 
tás gyönyöreivel és gyötrelmeivel. 


Az alapprobléma 

Miért kell egyáltalán törődnünk az útválasztással? Miért nem 

oldják meg a gépek önállóan ezt a feladatot? Mert a két pont 

közötti csomagátvitelért felelős IP protokoll nincs felkészítve 

ilyesmire (!), lehetőségei nagyon is korlátozottak: egyszerűen 

nem is teszi lehetővé egynél több hálózat használatát! Az 

eredeti IP specifikáció ugyanis két, egymással szorosan össze- 

függő korlátozást is tartalmaz egynél több hálózat esetére: 

1. szabály: Minden gép csak a saját hálózatára küldhet cso- 
magot. 

2. szabály: Ha mégis távoli hálózatra kellene küldeni a cso- 
magot, akkor az első szabály lép életbe. 

Tisztára, mint a ,férjnek mindig igaza van" feliratok az 

ajándékbolt falán. Vagy mint egy börtön: minden alhálózat 

egy-egy külön börtön. 

3. szabály: A rabok kintről csak az őröktől kaphatnak cso- 
magot. 

4. szabály: Ha mástól jönne a csomag, akkor az első szabály- 
lépne életbe. 

Egymással természetesen szabadon, a fegyőr közvetítése 

nélkül is kommunikálhatnak: arra való a radiátorcső :-) 

Az őrök , segítsége", közreműködése nélkül nincs lehetőség 

külső kapcsolatra. Ugyanez a helyzet az IP-vel. Amint külső 

hálózatra forgalmazunk, rá kell vennünk a fegyőrt, hogy se- 

gítsen. Mindenképpen szükségünk van egy segédre, egy pos- 

tásra, egy útválasztóra. Egyszerű esetben alhálózatonként 
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egyetlenegy ,fegyőr" van - ennek címét írjuk be a Default 
Gateway, vagy magyarul alapértelmezett átjáró helyére. 


Internet 


IP: 86.86.86.23 


IP: 172.16.0.1 


IP: 172.16.0.22 
SM: 255.255.255.0 
DG: 86.86.86.23 


5 Mi a hiba a fenti ábrán? (Rossz a DG.) 


Gyakori hiba, s MCP vizsgákon számtalan ravasz formában 
visszatérő feladat a Default Gateway helyes beállítása. A fen- 
tiek alapján egyértelmű, hogy ha egy számítógépen a beírt 
Default Gateway nem a saját routerünk innenső IP címe, ha- 
nem mondjuk például a túlsó lábát, vagy ad abszurdum az 
Elender egyik gépét adjuk meg (mondván, hogy az közelebb 
van az Internethez, hű de jó gyors lesz a kapcsolat), akkor a 
gép nem lesz képes külső kapcsolatot építeni. Idegen nem áll-. 
hat szóba velünk a saját fegyőrünk közvetítése nélkül! Nincs 
csalási lehetőség: ha nem él, vagy nem ismert a kapu őrzője, 
nem jöhet létre a kommunikáció a külső és belső felek között. 
A fegyőrös hasonlat egyetlen ponton sántít: ha hibás címet 
adunk meg alapértelmezett átjáróként, akkor nem a fegyőr 
állítja meg a forgalmat - odáig el sem jutunk. Az IP stack 
helyes átjáró hiányában helyben eldobja a kifelé irányuló 
csomagokat. A szétválasztás egyébként a saját és a címzett 
IP címéből képzett úgynevezett Network ID-k összehasonlí- 
tásán alapul: ha a két NetID azonos, közös alhálón va- 
gyunk. Ha nem - nem. A művelet a saját Subnet Mask se- 
gítségével történik olymódon, hogy a Maskkal kétfelé vág- 
juk a címeket, és ha a ,bal" fele (Network ID) azonos a rab 
börtönazonosítójával, akkor irány a radiátor. A következő 
ábra az előző alapján készült, ahol immár helyes a DG címe, 
és megpróbáljuk megpingelni a 23.23.23.23 című gépet. Az 
ábra alsó felében látható, ahogyan a gép eldönti, vajon 
azonos hálón van-e a végállomással. 
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Internet 


PING 23.23.23.23 


IP: 86.86.86.23 
M1 


IP: 172.16.0.1 


IP: 172.16.0.22 
SM; 255.255.255.0 











Nem egyforma! 


DG: 172.16.0.1  4§—  mostjó! 
nyissz! 

Network ID ; Host ID 
172. 16. 0 ; 22 
23. 23. 23 8 vél 
255.255.255 § o 


o Az útválasztás módszere: az IP címek szétvágása a 
Subnet Mask segítségével. 


Itt jegyzem meg, hogy manapság minden Subnet Mask bal- 
ról csupa egyes, jobbról csupa nulla, például: 


255.255.192.0-11111111.11111111.11000000.00000000 
Az eredeti szabvány megengedett ,fésűs" maszkot is, 
melyben vegyesen szerepelhettek egyesek és nullák. Ezt 
egy későbbi RFC felülbírálta, valószínűleg azért, mert nem 
embernek való a vegyes maszkkal történő fejben számolás. 


Minden Windows router? 

A legelső szabálypár miatt minden fegyencnek el kell tudnia 
dönteni, hogy kommunikációs partnere belsős, vagy külsős. 
Ezen döntések meghozatalára minden IP alapú eszköznek 
szüksége van, azaz mindegyik IP eszköz egy-egy egyszerű 
útválasztó is egyben. Erről könnyen meg is győződhetünk, 
ha parancssorban kiadjuk a ROUTE PRINT parancsot. Az 
alábbi ábrán például egy Windows 2000 Professional (!) út- 
vonaltábláját láthatjuk, ennek sorai egy-egy feldolgozandó 
irányt jelölnek. Későbbi példáim könnyebb értelmezhetősé- 
ge miatt célszerűnek tartom a táblázat részletesebb elemzé- 
sét - hamarosan route tábla műtétre is sor kerül! 


tech.net! 


RRAS (II. RÉSZ) - ŰTVÁLASZTÁSI ALAPOK 








5 A Windows 2000 Professional útvonaltáblája 


A táblázat első két oszlopában a célhálózatokat olvashat- 
juk, a szokásos formában: 


IP címtartomány eleje Subnet Mask 


199.188.177.0 255.255.255.0 


Ez a két szám egyértelműen meghatároz egy IP tarto- 
mányt. Könnyedén kiszámítható a vége, a Subnet Mask 
ugyanis megadja, hogy hány IP cím esik ebbe a tartomány- 
ba: ahol nulla áll a maszkban, az mind ide tartozik (az a 
szabadságfokunk) , ergo az utolsó IP cím ebben a kupacban 
a 199.188.177.255. Újabb dokumentumokban egy másik 
jelölésmód is előfordul: 


199.188.177.0/24 


A törtjel utáni szám megadja, hogy a Subnet Maskban hány 
egyes (1) bit van, a 24 tehát megegyezik a 255.255.255.0-val. 
A fenti ábrán látható útvonaltáblában tehát a következő 
hálózatok szerepelnek: 

















IP bij Hálózat 

0.0.0.0 0.0.0.0 Default Gateway 

127.0.0.0 255.0.0.0 SELF 

172.16.0.0 255.255.0.0 Saját alháló 

172.16.0.111 255.255.255.255 Ezagép 

172.16.255.255 255.255.255.255  Subnet Broadcast 

224.0.0.0 224.0.0.0 Multicast 

255.255.255.255 — 255.255.255.255 Globális IP 
Broadcast 


A következő két oszlop a küldési MÓDSZER meghatározásá- 
ra való. Alapvetően háromféle módszer létezik: 


Ha a 3. oszlop... ...a továbbítás 


egy ,idegen" IP cím a Célzott. A csomag az ,idegen" 
saját hálónkról (router, fegyőr) címre kézbesí- 





(Itt: 172.16.0.1) tendő 
saját címünk Üzenetszórás. Az Ethernet majd 
(Itt: 172.16.0.111) lerendezi. 





127.0.0.1 Lokális. A csomagot nem KI, 
hanem BE kell küldeni az 


oprendszerbe. 


Az Interface oszlopban a fenti három továbbítási mód ki- 
járatait, hálókártyáit láthatjuk, végül a Metric oszlop 
egyelőre nem fontos, majd ha jönnek a Routing protokol- 
lok, visszatérünk rá. 
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5 Mi hova? 


A kiemelt sor értelmezése ezek szerint: a 172.16.0.111 cím- 
re ,induló" (valójában érkező) csomagokat a 127.0.0.1 
(SELF) címre kell továbbítani, tehát be a gépbe. De az is 
kiolvasható, hogy ha a célgép IP címe mondjuk 
193.193.193.193, akkor ... hogyis? Meg kell keresnünk a 
193.193.193-as subnetet a legelső oszlopban, s ennek sorá- 
ból kiderül, hogy hova kézbesítendő. Nos, 193-as sort nem 
találunk, de ott a 0.0.0.0, mely minden ismeretlen címre vo- 
natkozik, ,mindent visz": a 193-as címek, mint teljesen is- 
meretlenek, célzottan a 172.16.0.1-es címre továbbítódnak, 
ami nem más, mint a DG. Ezzel a trükkel megspórolhatóvá 
vált, hogy a világ összes IP tartományát fel kelljen sorolni a 
listában: ami nincs bent, azt lenyeli a 0.0.0.0 sor. 

A saját hálózatra való csomagok célcíme egészen másképp fest: 
mintha önmagunknak küldenénk (127.0.0.1 cs 172.16.0.111)! 
A paraméter helyes értelmezése: ezen a címen/kártyán kell 
kieregetni, de nem kell vele célozni", az Ethernet majd elinté- 
zi a célba juttatást (üzenetszórás, ARP stb.). 

Fontos még ismerni a 127.0.0.1 címet: ezek megint mi va- 
gyunk, ez a speciális IP cím minden gépen önmagára mu- 
tat. A sor értelmezése: ami nekünk jött, az nekünk jött. 
Nem kell továbbküldeni. Ha megpingeljük ezt a címet 


PING 127.0.0.1 


Network Monitorral megfigyelhető, hogy a csomag ki sem 
jut a kábelre (nem látszik belőle semmi). Most lássuk, mit 
kell tennünk az útvonaltáblával a következő esetekben! 


Két hálózat összekapcsolása 

Ha mindössze két hálózatot (mondjuk két irodát) szeret- 
nénk összekapcsolni útválasztóval, nem kell törődnünk sem 
az RRAS útvonaltáblájával, sem a telepítővarázslóval. A lé- 
nyeg, hogy az RRAS routing engedélyezve legyen. Ilyenkor 
elegendő, ha az RRAS gépbe beteszünk két kártyát, azokon 
beállítunk két helyes IP címet, a két oldal munkaállomásai- 
nak DG-jét pedig egyszerűen az RRAS-ra irányítjuk. Ez azért 
elegendő, mert bár a munkaállomások ,ismeretlen" cím 
miatt, a 0.0.0.0 címre küldik a csomagokat, a középen álló 
RRAS mindkét hálózatról tud, így minden beérkező csoma- 
got ügyesen átemel a másik lábára. 







Scope 1 Scope 2 


DG:IP1 DG:IP2 
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5 Két alhálózat összekapcsolása 
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ÚŰTVÁLASZTÁSI ALAPOK 


Még egyszerűbb a hálózat gépeinek felkészítése, ha az RRAS- 
ra felteszünk egy DHCP Servert, és mindkét kártya IP címtar- 
tományára felveszünk egy scope-t (IP cím készletet), ahol a 
DG mindkét szkópban a megfelelő RRAS lábra mutat. Többkár- 
tyás gépen ennél többre nincs is szükség, mert a DHCP Server 
meg tudja különböztetni egymástól a bejövő kéréseket, és au- 
tomágikusan a megfelelő tartományból ad címet. 


Három alhálózat összekapcsolása 

Három hálózat láncba fűzése esetén azzal kell számolnunk, 
hogy a lánc végén tanyázó routerek már nem fogják ismer- 
ni a kettővel odébb található alhálózatot, mert oda nincs 
közvetlen hálózati kapcsolatuk. Lássunk példát! 











3. hálózat 
192.168.1.0 


2. hálózat 
172.16.2.0 


1. hálózat 
10.10.10.0 





5 Három alhálózat esetén már lesznek a routerek szá- 
mára ismeretlen, , távoli" hálózatok is 


Itt R1 számára a 3. hálózat közvetlenül már nem érhető el, is- 
meretlen. Első ránézésre úgy tűnik, hogy elkerülhetetlen R1 
és R2 felokosítása, útvonaltáblájuk felkészítése a távoli célok 
eléréséhez, hisz ha az 1. hálózat egyik munkaállomása R1-hez 
továbbít egy csomagot, melynek végcélja a 3. hálózat, akkor 
R1 csak néz bután, nem tudja merre van a tovább. 

Egy kis furfanggal azonban elodázhatjuk az útvonaltábla hek- 
kelését. Mit is kell csinálni minden ismeretlen csomaggal? 
Hozzávágni a DG-hez! Mi tiltja meg, hogy R1-nek is beállítsunk 
DG-t? A következő ábrán a görbe nyilak a csomagátdobás út- 
vonalát mutatják, ha mindkét routeren felvesszük a MÁSIKAT 
DG-nek. Fűszerezzük meg az egészet egy kis DHCP-vel is, és 
igazán könnyen kezelhető hálózathoz jutunk! 








Scope 1 Scope 2 


DG:R1 






3. hálózat 
192.168.1.0 


2. hálózat 
172.16.2.0 


1. hálózat 
10.10.10.0 














Átdobás 





DHCP Relay Agent 


5 Három hálózat, routolás és DHCP 


A fenti ábrán a DHCP Servernek már három szkópja (IP cím- 
készlete) van, de csak kettő alhálózat gépei képesek köz- 
vetlenül címet kérni tőle. A harmadik hálózaton ilyen ese- 
tekben el lehet helyezni egy DHCP Relay Agentet, mely on- 
nan a DHCP címkérési broadcastokat unicasttá alakítva át- 
dobja a routeren túlra, majd a választ ismét broadcasttá 
alakítva visszajuttatja a kérelmezőhöz. 
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Alapprobléma II. - gép a köztes hálózaton 

Három alhálózatból álló környezetben már előáll az a prob- 
léma, amit az augusztusi NetMon cikkben részletesen ele- 
meztem: a középső, második hálózaton mi legyen a munka- 
állomások DG beállításával? Ha R1, az is rossz, ha R2, az is 
rossz, hisz mindkét esetben menthetetlenül duplázott há- 
lózati forgalom kerekedik, amint az ,ellentétes" irányba 
szeretnénk küldeni valamit. Egyszerre kettő DG nem lehet, 
mert - mint emlékszünk - hiába adunk meg egynél többet, 
hármat vagy négyet, sajnos már a másodikat sem használ- 
ja a masina mindaddig, amíg az első elérhető. Emlékszik 
még valaki, mi erre a megoldás? A köztes gép útvonaltáb- 
lájának kiegészítése, amit okos routerek esetén maga az út- 
választó elintéz, ICMP Redirect üzenetek kiküldésével. A II. 
alapprobléma sokszorosan visszaköszön, ha hálózatunk 
egyre több alhálózatból épül fel, és eljön az a bonyolult- 
ság, amikor az ICMP Redirect nem oldja meg a problémát. 
Nem marad más hátra, hozzányúlunk az útvonaltáblákhoz... 


Négy hálózat összekapcsolása 

Ahogy bonyolódik a hálózat, úgy válik egyre nehezebbé 
pusztán ravaszsággal megúszni az útválasztótábla matatá- 
sát. Ha már négy hálózat felfűzésére van szükség... 












1. hálózat 
10.10.10.0 


2. hálózat 
172.16.2.0 





5 Négy alhálózat összekapcsolása 


... akkor már nem segít a DG-trükk, ugyanis a középen álló 

R2-nél a ,gép a köztes hálózaton" esete forog fenn, és két 

DG-t kellene beállítani neki, ami nem megy. Nézzük meg, 

vajon R1 és R3 esetén beválik-e még a DG-csel: 

0 R1 ismeri az 1. és a 2. hálózatot. 

Ha minden további ismeretlen csomagot gondolkodás 

nélkül áthajít R2-nek, akkor jól továbbítja a 3. és 4. 

hálóra való csomagokat! 

"0 Ennek tükörképe az R3, mely így szintén jól működik, ha 
a DG-je ,középre", R2-re mutat. 

Az R2 tanítása viszont elkerülhetetlen. Ismerkedjünk meg 

a Route parancs használatával! 


4 


ROUTE ADD Új bejegyzés készítése az útvonaltáblába 
ROUTE CHANGE Meglévő bejegyzés módosítása 
ROUTE DELETE Sor törlése a táblából 








Így taníthatjuk meg R2-nek, merre van az első hálózat: 


route add 


172.16.2.33 


10.10.10.0 mask 255.255.255.0 
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Ahol a 172.16.2.33 cím R1 , innenső" lába. Hasonlóképpen 
tanítható meg neki a negyedik hálózat holléte: 


route add 4.4.4.0 mask 255.255.255.0 192.168.1.111 


ahol 192.168.1.111 az R3 , innenső" lába. Szabadon kísér- 
letezhetnek Kedves Olvasóink a route tábla rongálásával, 
mert egyfelől mindig rendelkezésre áll a ROUTE DELETE, 
másfelől minden bajtól megszabadít egy jóízű reboot. Így 
nyugodtan kipróbálható, mit szól a masina, ha kiadjuk a 
következő parancsot: 


ROUTE DELETE 0.0.0.0 


Megszűnik a távoli hálózatok elérhetősége, de a dolog nem 
halálos, a 


route add 0.0.0.0 mask 0.0.0.0 172.16.0.1 


visszateszi a DG címet (Ahol a 172.16.0.1 a Kedves Olvasó 
alhálózatán lévő router címe)! 


N darab hálózat összekapcsolása 

A következő megoldandó probléma N darab alhálózat össze- 
kapcsolása. Az eddigiekből könnyen belátható, hogy a vége- 
ken található routerek esetén van némi remény DG-trükkre, 
de csak addig, amíg azok összesen két hálózat összekötését 
végzik. Ha elkezdünk pókhálót alkotni, azonnal elillan en- 
nek esélye, s marad a tanítás. Sajnos a routerek és útvona- 
lak számával exponenciálisan növekszik a szükséges 
ROUTE ADD parancsok száma, és akkor még nem beszéltünk 
a hálózat önkarbantartásáról. Körülbelül négy hálózatig ér- 
demes kézzel bíbelődni az útvonaltáblákkal, ennél összetet- 
tebb hálózatok esetén kézimunkázni őrültség. 

A megoldást valamilyen útválasztó protokoll használata je- 
lentheti, melyek közös tulajdonsága, hogy az egyes route- 
rek által természetesen ismert hálózatok adatait automati- 
kusan átvezetik a többi routerre is. Természetesen ismert 
hálózatnak nevezem azokat, melyek közvetlenül a masiná- 
ba csatlakoznak: nem kell megtanítani egy routert olyan 
hálózat elérésére, mely közvetlenül csatlakozik hozzá! 

Két útválasztó protokollról szólunk a következő hónapban: 
a RIP és az OSPF-ről, sőt, megemlékezünk a hamis IP címek 
által okozott útválasztási agyrémekről is. 


Fóti Marcell 
marcellf-onetacademia.net 
MCSE, MCT, MCDBA, MZ/X 
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Időzítés 


Időzítés és prioritás 

Az előző számban megjelent cikk folytatásaképpen a követ- 
kező oldalakon kicsit részletesebben bemutatjuk a Windows 
NT/2000 végrehajtási szálakat időzítő rendszerét, annak 
szabályait. Cikkünk - az előző részhez hasonlóan - David 
Solomon [1] Barcelonában, a Tech.Ed 2001-en elhangzott 
előadása, valamint ugyanő és Mark Russinovich Inside Mic- 
rosoft Windows 2000 (Third Edition) [2] című könyvének 
aktuális fejezete alapján készült. Ez a könyv egyébként 
ajánlott, sőt, kötelező olvasmány mindenkinek, aki szeret- 
ne komolyabban foglalkozni a Windows lelkivilágával. 


Egy kis ismétlés 

Foglaljuk össze az előző számban leírtakat: a Windows 
NT/2000 (továbbiakban csak Windows, különös tekintettel 
arra, hogy nem a Windows 9x családról van szó) operációs 
rendszer szinten végrehajtási szálakat futtat. Minden vég- 
rehajtási szál valamilyen processzhez tartozik (egy processz- 
hez akár több is); ezek a processzek képezik a tulajdonkép- 
peni alkalmazásokat. A processz nem más, mint az általa 
birtokolt végrehajtási szálak részére fenntartott adminiszt- 
ratív objektum és közös memóriaterület - a végrehajtási 
szálak időzítésében általában nem játszik szerepet. Kivételt 
képez ez alól a prioritás esete; az induló végrehajtási szá- 
lak kezdetben a szülő processz prioritásértékét öröklik, és a 
felhasználói felületen is csak a processz (és általa az összes 
hozzá tartozó végrehajtási szál) prioritása módosítható. 

A Windows 32 prioritási szintet kezel; a magasabb érték 
magasabb prioritást jelent. A 32 prioritási szint két fő rész- 
le oszlik: az alsó félben (0-15) az úgynevezett dinamikus, 
a felső félben (16-31) pedig az úgynevezett valósidejű 
prioritásértékek találhatók. A 0 prioritásértéket kötelezően 
a Zero Page Thread viseli (lásd a Windows memóriakezelésé- 
ről szóló cikket az előző számban). 
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5 A Windows 32 prioritási szintje és a prioritásosztályok 


elhelyezkedése 
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Szálak 
(II. rész) 
és prioritás 


A fenti ábrán a Windows 32 prioritási szintje mellett a felhasz- 
nálói felületen keresztül is elérhető, úgynevezett , prioritás- 
osztályok" találhatók. A processzek (és rajtuk keresztül a vég- 
rehajtási szálak) prioritását ugyanis mi, a felhasználó is meg- 
határozhatjuk és módosíthatjuk. Futás közben a Task Manager- 
ben jobb gombbal kattintva kiválaszthatjuk a kívánt prioritást. 


lol2d 


8 Windows Task Manager. 











End Process Tree 
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5 Processz prioritásának módosítása futás közben a 
Task Manager segítségével 


Az egyes prioritásosztályok beállítása során a processz az 
előző ábrán látható középértéket kapja (a Normál prioritás 
középértéke például 8). A prioritás indítás előtti beállításá- 
nak egyetlen módja a start parancs, amelynek paraméter- 
ként átadhatjuk a kívánt prioritásosztályt, valahogy így 
(lásd még: start /?): 


start /low notepad.exe 


start /abovenormal notepad.exe 


A processz (figyelem! nem a végrehajtási szál!) aktuális, 

alap (bázis) prioritásosztályát a Task Manager-ben, a Base" 
Priority oszlopban láthatjuk, de jobban járunk ha (például) 

a Windows 2000 Support Tools-ból futtatjuk a Process Vie- 

wer-t (pview.exe), mert akkor nemcsak a bázisprioritást, de 

a végrehajtási szálak aktuális (current) prioritásértékeit is 

megleshetjük. A végrehajtási szálak státuszának és prioritá- 

sának másik jó megfigyelőeszköze a Performance Monitor 

(használatát az előző számban már bemutattuk). 


Az operációs rendszer magja (a kernel) valósidejű 
prioritású végrehajtási szálakat futtat. Legyünk óvato- 
sak a valósidejű prioritás használatával, mert előfor- 
dulhat, hogy létfontosságú I/O végrehajtási szálaktól 
vesszük el a futási időt. Az általa elérhető végrehajtá- 
si szálak prioritását bármelyik felhasználó módosít- 
hatja, egy korlátozással: valósidejű prioritást csak az 
állíthat be, aki rendelkezik az ,Increase scheduling 
priority" privilégiummal - ez alapértelmezésben csak 
az Administrators csoportra érvényes. Ha a prioritást 
módosítani próbáló felhasználó ezzel a privilégiummal 
nem rendelkezik, a processz valósidejű helyett , High" 
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(dinamikus) prioritásosztályba kerül. Végül: meg kell 
jegyeznünk, hogy miközben a valósidejű prioritások- 
ról beszélünk, a Windows nem igazi valósidejű (real- 
time) operációs rendszer (Id. még: [3]). 


Alap és pillanatnyi prioritás 

Egy végrehajtási szál pillanatnyi prioritásértéke két részből 

áll össze: 

"0 A végrehajtási szál alapprioritása (base priority). 

"0 A relatív prioritás (priority boost) , ami az alapprioritás- 
hoz hozzáadódik, és értéke idővel változhat. 

A priority boost-ról később még lesz szó, de azt már most el- 

mondhatjuk, hogy a valósidejű prioritásértékkel futó végre- 

hajtási szálaknál a rendszer nem használja - ezek pillanatnyi 

prioritásértéke mindig megegyezik az alapprioritással (ezért 

hívják a nem valósidejű prioritásértékeket dinamikus prioritás- 

nak). A végrehajtási szálak futtatásának időzítéséhez az idő- 

zítő (dispatcher) mindig a pillanatnyi prioritást ellenőrzi. 





A dispatcher várakozási sor-adatbázisa 

A végrehajtási szálak időzítését végző komponens, a dis- 
patcher (ami a maga valójában nem is létezik, feladatát 
kernelszerte elszórtan található összetevők végzik) minden 
prioritásértékhez egy-egy várakozási sort tart fenn. Ezek- 
ben a várakozási sorokban találhatók a futásra kész (Rea- 
dy állapotú) végrehajtási szálak. A dispatcher adatbázisát 
a következőképpen ábrázolhatjuk: 


Default base priority 
Default processor affinity 


Default guantum 


Dispatcher ready gueue 


Process Process 


Base priority 


Current priority 
Processor affinity 
Ouantum 
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5 A Dispatcher várakozási sor-adatbázisa 


Az ábra bal oldalán láthatók a különböző prioritásértékhez 
rendelt várakozási sorok (Dispatcher ready gueue). Az 
adatbázis a feldolgozás meggyorsítása érdekében két 
összegző mezőt is tartalmaz: 

"0 A Ready summary bitmező valamely bitjének értéke azt 
jelzi, hogy az adott prioritású várakozási sorban talál- 
ható-e futásra kész végrehajtási szál (azaz érdemes-e 
egyáltalán benézni a várakozási sorba). 

Az 3 bitmező pedig processzorokat tartal- 

maz: a bitek értéke az adott processzor szabad (idle) 
állapotát jelzi. Találós kérdés: legfeljebb hány pro- 
cesszort képes használni a jelenlegi legizmosabb Win- 
dows, a Datacenter Server? 

A legfontosabbak mégiscsak a várakozási sorok: amikor a 
Windows a következő nyertes végrehajtási szálat keresi, 


o 
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ezeket a várakozási sorokat ellenőrzi, a legmagasabb prio- 
ritásútól a legalacsonyabbig. Ha egy várakozási sorban ta- 
lálunk futásra kész végrehajtási szálat, ő léphet futó stá- 
tuszba. Ha egy a várakozási sorban egynél több futásra 
kész végrehajtási szál található, a dispatcher igazságos 
módon körbe-körbe adja majd a futási jogot (round-robin) . 
Ne feledjük, ez az igazságosság csakis azonos prioritású 
végrehajtási szálak között érvényes, az alacsonyabb priori- 
tással rendelkezőkkel szemben sokkal keményebben visel- 
kedik a Windows: amíg magasabb prioritású szál futásra 
kész, bizony az alsó házakban semmi sem történik. 

Ennek demonstrálására készítettünk egy kis példaprogra- 
mot (a [4] címről letölthető) : 


(ETO E TESz EN 


5 Harcban a processzorért: a 
két processz nagyjából egy- 
szerre indult, különbség csak a 
prioritásukban van 


Az ábrán látható tesztalkalmazás egyvalamire képes: szá- 
mol. Teszi ezt addig, amíg a CTRL--C billentyűkombináció le- 
nyomásával meg nem állítjuk. Az st.bat a start parancs se- 
gítségével gyors egymásutánban kétszer elindítja ugyanazt 
az alkalmazást, először egy alacsonyabb, majd egy maga- 
sabb prioritással. Az eredmény önmagáért beszél. Ha kipró- 
báljuk, érdemes megfigyelni, hogy a futásidő eloszlása ko- 
rántsem sima: amikor néha végre az alacsonyabb prioritású 
végrehajtási szál is szóhoz jut, gyors egymásutánban 15-20 
sort ír a képernyőre, majd újabb hosszú szünet következik. 

Látható, hogy a magasabb prioritású processz (és az ő 
egyetlen végrehajtási szála) több nagyságrenddel többet fut- 
hat, mint az alacsonyabb prioritású változat. Az érdekes az, 
hogy ez utóbbi is szóhoz jut néha... nem mond ez ellent a 
pár sorral ezelőtt említetteknek? Nos, nem: az alacsonyabb 
prioritású processz nyilván akkor futhatott, amikor a maga- 
sabb prioritású éppen nem volt futásra kész állapotban (pél- 
dául mert I/O műveletre várt), de az is lehet, hogy az ope- 
rációs rendszer mentette meg az , éhhaláltól" - lásd később. 


A működő rendszer egyik kulcsa a várakozás 

A végrehajtási szálak leggyakoribb állapota a várakozás 
(wait state). Egy szál sok mindenre várhat: I/O művelet 
befejezésére, másik végrehajtási szál lefutására, különféle 
rendszereseményekre, sült galambra (ami tíz másodperc 
múlva érkezik) - ezek mindegyike annyiban hasonló, hogy a 
várakozás során a végrehajtási szál várakozó státuszba lép 
(onnan majd az adott esemény bekövetkeztekor maga a Win- 
dows lépteti vissza). A várakozó státusz pedig nem futásra 
kész státusz, ezért ilyenkor végre feljöhetnek a felszínre az 
addig fuldokló, alacsonyabb prioritású végrehajtási szálak is. 
Van még más eset is, amikor a Windows (a Dispatcher) új- 
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ra kiértékeli, ki lehet a következő futó szál - jusson eszünk- 

be a felsorolás az előző számból: 

-B Új végrehajtási szál futásra kész - mert új szál jött létre, 
vagy tért vissza várakozó státuszból 

"0 Az éppen futó végrehajtási szál elhagyja a futó státuszt 

— mert lejárt a számára kijelölt időszelet; mert várakozó ál- 

lapotba lépett, vagy mert végleg befejezte a működését 

Valamelyik végrehajtási szál prioritása megváltozik - ha 

önmaga, vagy akár az operációs rendszer módosítja a 

szál prioritását 

"0 Ha a futó végrehajtási szál Processor Affinity értéke meg- 
változik 


A 


Priority Boost I/O műveletek után 

A felhasználó felé nyújtott optimális reakcióidők kialakítása 
érdekében a Windows bizonyos esetekben átmenetileg meg- 
növelheti egy-egy végrehajtási szál prioritását. Az I/0 műve- 
letet , végző" végrehajtási szál elküldi a kérést az eszközmeg- 
hajtónak, majd a művelet befejezéséig wait state-be kerül. 
Amikor a művelet befejeződik, a szál újra futásra kész stá- 
tuszba kerül, ráadásul a Windows átmenetileg a prioritását is 
megnöveli. Hogy ez a növelés milyen mértékű, azt az adott 
I/O eszköz eszközmeghajtója határozza meg. Az ajánlott ér- 
ték típusonként más és más (videó, lemez, CD-ROM, párhuza- 
mos port: 1, hálózat, soros port: 2, billentyűzet, egér: 6, hang: 
8). Ez az érték mindig a szál alapprioritásához adódik hozzá 
és az összeg soha nem lépi át a 15-öt (valósidejű prioritásnál 
pedig nincsen boost). A megnövelt prioritás csak rövid ideig 
érvényes, minden guantumegység lejártakor a prioritásérték 
is csökken eggyel, egészen addig, míg a végrehajtási szál új- 
ra el nem éri az alapprioritásértéket. 


Priority Boost az előtérben futó végrehajtási szálnak 

A Windows a wait state-ből visszatérő, előtérben futó vég- 
rehajtási szál prioritását is megnöveli, mégpedig az előző 
számban bemutatott Win32PrioritySeparation registry érték 
alsó két bitjén beállított értékkel (a Ouantum boost-nál ez 
csak egy mutató volt (,Boost értéke"), ezesetben viszont 
maga az érték számít) . Ez az érték a végrehajtási szál pilla- 
natnyi prioritásához adódik hozzá. Hasonlóképpen, további 
2 boost-ot kap minden végrehajtási szál, ami ablakkezelő 
üzenetet kap (ablak mozgatása, méretezése, stb). 


Priority Boost az , éhhalál" (starvation) ellen 

Minden operációs rendszer egyik fő problémája az alábbi: te- 
gyük fel, hogy egy 7-es prioritású szál fut; egy 11-es priori- 
tású szál egy olyan erőforrásra vár, amit éppen egy 4-es 
prioritású szál birtokol... A számlálós példában láthattuk, 
hogy a nagyétkű 7-es miatt a 4-es prioritású szál bizony 
nem lesz képes befejezni a munkáját, és elengedni az erő- 
forrást - az eredmény az, hogy a 11-es prioritású szál is 
éhenhal. Az ilyen helyzetek elkerülése érdekében a Windows 
kernel ,Balance Set Manager" nevű komponense folyamato- 
san ellenőrzi, hogy mely végrehajtási szálak 
nem jutottak szóhoz az elmúlt 300 órajel-in- 
tervallumban (300x10ms - kb. 3 másodperc). 
Ha talál ilyet, a szegény elnyomott végrehaj- 
tási szál prioritását 15-re emeli, és dupla Ou- 
antumot ad neki (!). Ezidő alatt a szál léleg- 
zethez juthat. A dupla időszelet lejárta után 
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azonnal minden (prioritás) visszatér a régi kerékvágásba. 
Indítsuk csak el újra a példaprogramocskát! Nem feltűnő, 
hogy az alacsonyabb prioritású végrehajtási szál kb. három 
másodpercenként jut szóhoz? :-) Természetesen ez a mód- 
szer sem tökéletes, ráadásul a Balance Set Manager (telje- 
sítményokokból) egyszerre csak 16 elnyomott végrehajtási 
szálat ellenőriz - de az esetek többségében ez a kis segít- 
ség elég a patthelyzetek (deadlock) elkerülésére. 


Többprocesszoros rendszerek 

Többprocesszoros rendszerben a végrehajtási szálakhoz úgy- 

nevezett processzor-affinitást rendelhetünk. Ez tulajdonkép- 

pen nem más, mint egy maszk, ami meghatározza, hogy az 

adott végrehajtási szál melyik processzor(ok)on futhat, és 

melyeken nem. Még két másik fogalmat kell tisztázni: 

0 Ideal Processor: a végrehajtási szál létrehozásakor a Win- 
dows véletlenszerűen hozzárendel egy , kedvenc" processzort. 

8 Last Run Processor: az a processzor, amelyen a végrehaj- 
tási szál utoljára futott. 

Amikor egy végrehajtási szál futásra kész állapotba lép, a Win- 

dows szabad (idle) processzort keres a számára. Ha megtehe- 

ti, a végrehajtási szál ideális processzorát választja; ha az nem 

szabad, a last run processzort; ha pedig az sem szabad, akkor 

a Dispatcher adatbázisból keres egy ráérő példányt. 

Ha nincs szabad processzor, akkor a Windows megkeresi az 

első, a végrehajtási szál által használható processzort, és ha 

azon a végrehajtási szál prioritásánál alacsonyabb prioritású 

szál fut (running), vagy készül a futásra (standby) , akkor át- 

veszi annak a helyét (ez a preemption). Ha a prioritás nem 

elegendő, a Windows nem keres másik processzort a végre- 

hajtási szálnak, hanem azt a várakozó sorba helyezi. 

Amikor egy processzor felszabadul, az egyprocesszoros 

rendszerekkel ellentétben a Windows nem az első futásra 

kész végrehajtási szálat indítja, hanem előbb azt, amelyik 

megfelel az alábbiak valamelyikének: 

-? Utoljára az adott processzoron futott 

8 Az ideális processzora az adott processzor 

8 Legalább két Ouantum óta futásra kész 

-? 24, vagy nagyobb a prioritása 


Végül... 

Szeretnék bemutatni egy, a weben talált tanulságos szimu- 
lációt. Kattintsunk a [5] címre, és elénk tárul egy kétpro- 
cesszoros rendszer (Flash plug-in szükségeltetik), ahol kö- 
vethetjük a három processz négy végrehajtási szálának fu- 
tását. A végrehajtási szálak processzor-affinitást is tartal- 
maznak, a szimulációt a , Clock" feliratú kapcsoló nyomoga- 
tásával léptethetjük. Jó szórakozást! 


Fülöp Miklós 
mick Onetacademia.net 


A cikkben szereplő URL-ek: 


[1] http://www.solsem.com 

[2] http://mspress.microsoft.com/prod/books/4354.htm 

[31 http://support.microsoft.com/support/kb/articles/094/2/65.ASP 
[4] http://technet.netacademia.net/download/threading 

[5] http://www.8Ogmultimedia.com/winnt/simulator.htm 
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XML-gessünk 


(II. rész) 


Bevezetés 

Két hónappal ezelőtti számunkban elindultunk az XML-hez 
kapcsolódó technológiák felidézésével. Ebben a számban 
utánajárunk az XML dokumentumok strukturális leírására 
szolgáló sémáknak, majd rátérünk az Internet Explorer XML 
képességeire. Ezen belül elmélyedünk az XML dokumentu- 
mok formázásában az XSL és a CSS alkalmazására. Az itt 
leírt alapok megteremtik azt a tudást, amely segítségével 
már ügyfél és kiszolgáló oldalon is tudunk XML dokumen- 
tum alapú weboldalakat építeni - melynek részleteit a kö- 
vetkező számban olvashatják. 


XML Stratégia 

Az XML technológia vívmányai, akár tetszik, akár nem, a 
nyakunkon vannak, és mielőbb alkalmaznunk kell tudni 
őket. Havonta 4-5 oldalban alig lehet valamit átadni ezek- 
ből a forradalmi módszerekből, mert ha alapozással akar- 
nánk kezdeni, akkor minimum a következő 10 cikk csak fo- 
galmak tisztázásával menne el, és még mindig nem tud- 
nánk használni az XML-t, csak értenénk, hogy mit takarnak 
azok az X-szel kezdődő néhány betűs rövidítések. Emiatt a 
cikksorozatomban hibrid stratégiát vezetek be. Minden 
szám elején lesz körülbelül egy oldalnyi bevezető, amely- 
nek célja néhány fogalom tisztázása az XML háza tájáról. A 
maradék oldalakat mindig valamilyen kézzelfogható, gya- 
korlatban azonnal alkalmazható példakódokkal fogom meg- 
tölteni. A két rész nem feltétlen fog szorosan összetartoz- 
ni, de egy közös kapocs lesz közöttük: mindkettő XML-ről 
fog szólni. Emiatt előfordulhat, hogy lesz a cikkekben egy- 
két fogalom, amit előtte nem definiáltam, de ilyenkor min- 
dig hivatkozni fogok egy-egy URL-re, ahol a fogalomról 
részletes információ kapható. Vágjuk hát bele! 


Sémaleírás 

Adott az XML, mint általános, egyszerű és hatékony adatleíró 
nyelv. Önleíró, azaz egy XML dokumentumot minden külső in- 
formáció nélkül értelmezni lehet, be lehet járni a benne talál- 
ható csomópontokat, kiolvasva az elemek értékét és attribú- 
tumait. Azonban irányított kommunikáció esetén, akár gépek 
közötti információcserénél, akár gép-ember kapcsolatban sok- 
szor szabályokat kell alkotnunk a küldendő illetve fogadandó 
XML dokumentum szerkezetére vonatkozóan. Ekkor már csak 
azokat az XML dokumentumokat fogadjuk el érvényesnek, 
amelyek szerkezete megfelel a formális leírásban szereplő fel- 
tételeknek. Például egy megrendelést leíró XML dokumentum- 
ra valószínűleg kikötnénk, hogy benne kell legyen a megren- 
delő neve, címe, adószáma satöbbi. Ha a kapott megrede- 
lés.xml-ben nem szerepel minden kívánatos adat, akkor 
visszadobjuk a megrendelést, mert nem érvényes. 

Az XML dokumentum szerkezetének, más néven sémájának 
leírására több módszer is a rendelkezésünkre áll, melyek fo- 
kozatosan, a használat során fejlődtek ki. Nézzük meg mi- 
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lyen hárombetűs rövidítések segítenek bennünket az XML 

dokumentumok sémájának leírásában: 

"8 DTD, Document Type Definition: [1] a legelső eszköz 
volt az XML dokumentumok struktúrájának leírására. 
Több sebből is vérzik, de a legnagyobb problémája: 
nem XML formátumú. Ha már egyszer kitalálták az XML- 
t, nagyon gyors és hatékony feldolgozót (parser) írtak 
hozzá, akkor miért nem lehet az elemzendő XML doku- 
mentum sémáját is XML-ben leírni? Emellett nincsenek 
benne adattípusok, mindent csak szövegként lehet de- 
finiálni, valamint nem támogatja a névtereket, amely 
nélkül szó sem lehet több forrásból összefűzött adatok 
ellenőrzésére. Ezek igen súlyos hiányosságok, amely 
miatt a DTD hamarosan ki fog halni, de egyenlőre saj- 
nos egyedül ez az egyetlen, végleges, elfogadott séma- 
leíró nyelv. 

"8 XDR, XML Data-Reduced: [2] a nagyreményű Microsoft 
DTD utód - volt. A Microsoft gyorsan lemondott a DTD 
használatáról, és gyors ütemben belekezdett egy XML 
formátumú sémaleíró nyelv kidolgozásába, amelyet a 
Word Wide Web konzorciumnak is elküldött szabványo- 
sításra. Megszületett az XDR. Amellett, hogy XML for- 
mátumú még jóval flexibilisebb is, mint a DTD. A DTD- 
ben leírt struktúrának maradéktalanul meg kell felelni 
egy XML dokumentumnak. Az XDR is tud ilyen szigorú 
lenni, de emellett elő lehet azt is írni, hogy az ellenő- 
rizendő dokumentum egyes részeiben lehetnek további 
elemek is, amelyet a séma nem ír le. Például egy sze- 
mélyről szóló XML adatlapban kötelezővé tesszük a név, 
születési dátum és az anyja neve elemeket, de ezen 
felül megengedjük, hogy egy buzgó gazdi például a ku- 
tyája nevét és haja színét is beleszerkessze a dokumen- 
tumba. A hangsúly nem azon van, hogy előírhatunk op- 
cionális elemeket, hanem azon hogy megengedhetünk 
olyan elemeket is, amelyekről a séma készítésekor még 
nem is tudtuk, hogy lesznek. Ehhez kapcsolódó szolgál- 
tatás, hogy XDR segítségével le lehet szabályozni a do- 
kumentum egy részét is, nemcsak a teljes egészet. DTD- 
vel természetesen csak az egész dokumentumra lehet 
szabályokat definiálni. 

Emellett az XDR bővíthető, azaz az igények megváltozá- 

sakor nem kell a sémát kidobni, csak egy másik névtér be- 

vezetésével kiegészíteni a meglevőt. Utolsó, de nagyon fon- 
tos szolgáltatás az XDR-ben, hogy az elemek és attribútu- 
moknak meg lehet adni a típusát (egész szám, dátum satöb- 
bi). A DTD-ben minden szövegként van deklarálva. A leg- 
több, a közeli múltban fejlesztett Microsoft termék XDR-t 
használ sémaleírásra. Azonban már a kapuban dörömböl az 

XSD, XML Schema Definition [3], amely a cikk írásának 

pillanatában a leginkább aktuális sémaleíró nyelv. A 

Biztalk Server, illetve a .NET XML osztályok már tudják 

- tudni fogják ezt a sémaleírást is kezelni (természete- 
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sen az XDR mellett) . A Visual Studio 7 egyik alapszolgál- 
tatása az XSD sémák grafikus szerkesztése, konverziója 
XDR-ből XSD-be, XML dokumentumból XSD generálása 
stb. (A Visual Studio 7 illetve a .NET stratégia fejlesztői 
szemmel nézve több, mint szenzációs. Újságunkban is rö- 


videsen megkezdjük az alapok lefektetését. ) 


Az XML és a Web. 

A Microsoft nagy erőkkel ráállt az XML technológiában rej- 
lő lehetőségekre, és ez az elkötelezettség meglátszik az 
utóbbi 3 év összes Microsoft termékén is. Az összes termé- 
ket áthatja az XML, legyen szó konfigurációs állományokról 
(.NET-ben minden konfigurációs adat XML fájlokban van, hel- 
lo registry - végre!), kiszolgáló termékekről, vagy az Inter- 
net Explorer-ről. Még azt sem tudtuk mi az az XML, de az 
IE4 már támogatta, persze az akkori szabványnak megfele- 
lően még eléggé gyerekcipőben, de már működtek benne 
nagyon hasznos funkciók. A Microsoft Internet Explorer 5 
már igen hatékony XML támogatást tartalmaz, amely segít- 
ségével az információk megjelenítéshez kapcsolódó funk- 
ciók jelentős részét ügyféloldalon meg lehet oldani, csök- 
kentve ezzel a szerver terhelését. Ezt mondják Amerikában, 
ahol tényleg agyonterhelik a webkiszolgálókat a szörfözők. 
Ezzel szemben nálunk, ahol örül egy webszájt, ha van napi 
5000 találata, inkább a lassú modemes kapcsolat miatti le- 
csökkent szerverhez fordulás az, ami miatt érdemes kihasz- 
nálni az IE-ben rejlő lehetőségeket. 

Persze általában az Internetes környezetben nem köthetjük 
ki a látogatóknak, hogy használjanak IE 5.5SP1-et, mert 
csak az tudja kihasználni az általunk megírt funkciót. Azon- 
ban heterogén böngészőkörnyezetben sem kell lemondani 
az XML kínálta előnyökről, csak buta böngésző esetén az 
XML-lel kapcsolatos funkciókat a kiszolgálón kell implemen- 
tálni, és csak a kész HTML kódot leküldeni a böngészőknek. 
Okos böngészőnek megy az XML, butának a HTML. Az okos 
keveset fordul a webszerverhez, a buta sokat. 


IE és XML, a két jó barát 

Csapjunk bele az IE5 XML szolgáltatásaiba. Ha egy XML ál- 
lományt adunk meg a böngészőnek, akkor ő azt közvetlenül 
megjeleníti. 
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0 Egy közönséges XML állomány az IE5-ben [4] 
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Figyeljük meg, az c?xml version-"1.0" encoding-"ISO- 
8859-2" ?: sort! Egyrészt leírja, hogy a dokumentum az 
XML1.0-s szabványra épül [5], valamint azt, hogy a benne 
található karaktereket az IS0-8859-2-es kódtábla alapján 
kell értelmezni. Ha ezt nem tesszük meg, az összes értelme- 
zőprogram, beleértve azt is, ami az IE mögött is van, kibo- 
rul az első ékezetes karakternél. Az IE5.5 így dohog: 


An Invalid character was found in text content. 
Line 6, Position 19 
SLZCSALADPXSOCczZ?SALAD2 


Jó, de ez így minden, csak nem felhasználóbarát. Alakítsuk 
át ezt HTML-é, amelyen keresztül már szépen, formázottan 
láttathatjuk az információkat. Két módszer kínálkozik erre, 
illetve egy harmadik, ami az első kettő keveréke. 

1. Írjunk egy Cascaded Style Sheet-et (CSS) [6], amiben 
leírjuk, hogy melyik elem hogyan jelenjen meg a bön- 
gészőben. Ez működő, de igen erősen behatárolt mód- 
szer, mert csak nagyon korlátozott lehetőségeink van- 
nak a cél HTML dokumentum formátumának meghatáro- 
zásában. Egyszerűen azért, mert a CSS nem erre van ki- 
találva. Arra nagyon jó, hogy leírjuk vele egy adott 
HTML elem megjelenését, de itt XML elemeket kellene 
transzformálni valamilyen, általunk definiált HTML for- 
mátumba, és erre a feladatra nem alkalmas a CSS. Vi- 
szont, erre van kitalálva az 

2. Extensible Style Language, röviden XSL [7]. Az XSL pont ar- 
ra van kitalálva, hogy tetszőlegesen bonyolult módon jele- 
nítsünk meg egy XML dokumentumot, ami nevezhetnénk 
adatforrásnak is, kihangsúlyozva, hogy az nem hordoz 
semmiféle megjelenítési információt. XSL segítségével 
könnyedén megváltoztathatjuk az adatok, elemek eredeti 
sorrendjét, megszűrhetjük a benne található adatokat, is- 
métlődéseket vihetünk be, stb. Egyszóval XSL segítségével 
olyan HTML kimenetet generálunk, amilyet csak szeret- 
nénk. Tulajdonképpen az eredeti XML dokumentumot bár- 
mi mássá is átkonvertálhatjuk vele, például egy másik XML 
dialektussá, azaz egy más struktúrájú XML dokumentum- " 
má, vagy éppen szöveges állománnyá! Amivé csak akarjuk. 
Nem véletlenül fejlődött ki az XSLT [8], az XSL Transfor- 
mations szabvány az XSL-ből. Az XSL esetén a kiinduló cél 
az XML adatok meg jelenítésének szabályozása volt - alter- 
natíva a CSS mellé. Az XSLT már kifejezetten annak fényé- 
ben készült, hogy az XML dokumentumokat valamilyen 
más formátumúra akarjuk átalakítani, transzformálni. 

Van XSLT-nk, amivel pompásan át lehet alakítani a megjeleníten- 

dő XML dokumentumot HTML-é. Azonban egy bonyolultabb XSLT 

transzformáció igen áttekinthetetlen tud lenni, és ha még ebbe 
képeket, formázó parancsokat, stílusokat is beleszövünk, akkor 
egy olyan XML-HTML-formázó. parancsok spagettit kapunk, ami 
karbantarthatatlan lesz. Ekkor jön a nyerő ötlet. XSLT-vel transz- 
formáljuk át a kívánatos HTML-é a forrás XML-t, és a formázások- 
ra csak hivatkozunk benne, de ne fejtsük ki őket az XSLT-ben. 

Ehelyett az összes formázó utasítást rakjuk ki CSS-be, és máris 

ötvöztük az XSLT flexibilitását a CSS szuper formázási képességei- 

vel. Mindeközben a grafikus bármikor nyugodtan átgyúrhatja a 

CSS-t, nem kell szembesülnie (és elszaladnia :) az XSLT-vel. 
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Az XSLT közbelép 

Most, hogy kipletykáltuk a grafikust, készítsünk egy XSL do- 
kumentumot, és adjuk meg a forrás XML-ünknek, hogy ami- 
kor a böngésző megjeleníti, használja az XSL-ünket. Ehhez az 
XML forrás elején megadjuk az XSL fájl elérését (na.xsl): 


c?xml version5-c"1.0" encoding-"ISO-8859-2"?5 
€c?xml-stylesheet type-"text/xsl" href-"na.xsl"?5 
LxNETACADEMIAZ 


A böngésző az XML állomány betöltésekor megnézi, hogy 
van-e XSL hozzárendelve. Ha van, akkor letölti azt is, és vég- 
rehajtja az abban leírt műveleteket, majd megjeleníti a vég- 
eredményt. Nézzünk egy egyszerű transzformációt: 


c?xml version-"1.0" encoding-"ISO-8859-2"?5 
$€xsl:stylesheet xmlns:xsl-"uri:xsl"5 
Sxsl:template match-"/"5 
XHTML? 
SCaHEAD3 
€link rel-"stylesheet" 
typez"text/css" hrefz"na.css" /5 -—(0) 
€/HEAD5 
LxBODY2 
CKTABLE CLASSz"OktatokTabla"5 
LXTR2 
LxTD2NévS/TD2 
LxTDI3Pozícióc/TD2 
cLxTDI:Telefonszámc/TD3 
CxTDPEMail címc/TD2 
£/TR2 
€xs1l:for-each 
select-"NETACADEMIA/OKTATÓ: 
LTR2 
€xs1l:apply-templates/5 -—() 
£/TR2 
£/xs1l:for-each2 
£/TABLEZ 
£/BODY5 
€/HTML2 


£xsl:template match5z"NEV"5 -——— 65 


LXxTD53Cxsl:value-of select-"CSALAD"/5 


£/xsl:templates 


£xsl:value-of select-"KERESZT"/5€/TD5 
£€/xsl:templates 


£xs1l:template match-"BEOSZTAS"5 


LxTDPXCxsl:value-of select-"."/5c/TD5 


£/xsl:templates 


€xsl:template match-"TELEFON"5 e) A 


LxTD53436 (Cxsl:value-of select-"KORZET"/5) 


£xsl:value-of select-"SZAM"/5€/TD5 
£/xsl:template2 
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€xsl:template match-"EMAIL"5 
cxTD3Cxsl:value-of select-—"."/5c/TD3 


£/xsl:templatez 
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£/xsl:stylesheet2 


Hogyan hajtja vége a böngésző az imént felvázolt transz- 
formációt? A E azt jelzi, hogy a match-ben megjelölt 
elemre, ami jelen esetben a gyökér elem (cNETACADEMIA:) 
hajtsa végre a záró tagig (7 leírt műveleteket. Mit jelent a 
végrehajtani? A nem XSL tagokat egyszerűen bemásolja a 
kimenetbe, így egészen a 8 pontig minden bekerül a vég- 
eredménybe. Jól látható, hogy itt egy HTML táblázatot 
hoztam létre, egy fejléccel. Az XML forrásból származó tar- 
talom generálása a 8 körül történik. Az xsl:for-each arra 
utasítja az XSL értelmezőt, hogy a select után megadott 
XPath [9] kifejezés által kiválasztott elemeken menjen vé- 
gig, és mindegyikre hajtsa végre az utasítás törzsében leírt 
parancsokat. A NETACADEMIA/OKTATO XPath kifejezés az 
összes, a NETACADEMIA elem alatt létrehozott OKTATO ele- 
mekre ad egyezést, azokat választja ki (jelen esetben csak 
egyet, de ha több ismétlődő OKTATO elem lenne a forrásban, 
akkor mindegyiket). Mi történik a kiválasztott elemekkel? 
Generálódik hozzájuk egy cTR: c/TR: páros, ami HTML-ben 
a táblázat egy sorát írja le. És a lényeg, a forrásadatok a 
Z kifejezés jóvoltából kerülnek bele a kimenetbe. Az 
xsl:apply-templates elem azt jelenti, hogy az éppen feldol- 
gozás alatt álló elemre nézze meg, hogy van-e egyező sab- 
lon létrehozva. Ha van, akkor azt végrehajtja, és annak a 
kimenete beleszövődik a Z kifejezés helyébe. Esetünkben 
a E paranccsal lefúrtunk az XML forrásunk cOKTATO: ele- 
méhez, így az €-- sablonok már erről a szintről indulnak, 
azaz a match attribútumokban megadott XPath kifejezések 
kiegészülnek így: /NETACADEMIA/OKTATO/TELEFON, mond- 
juk a va sablon esetén. Másképpen fogalmazva a forrás 
XML-ben a /NETACADEMIA/OKTATO/TELEFON elérési úttal 
jelzett elem elérésekor az XSL processzor meghívja a va 
sablont. A sablonon belül az xsl:value-of elem kiválasztja 
a select-"KORZET" által kijelölt elem értékét, azaz a 
-:KORZET:2c/KORZET: közötti szöveget cs. Néhány egyéb 
formázó karakter és a SZAM elem értékének felolvasása 
után a sablon véget ér. Ezután az XSL motor megnézi, 
hogy van-e még más sablon, ami egyezést mutat valame- 
lyik elemmel. Esetünkben mind a négy sablon szóhoz jut 
minden egyes oktatóhoz. 

Miután B végigment az összes elemen, kiíródik a táblázat 
vége, és véget ér a végrehajtás a É) ponton. 

Aki ezt az utat lelkiismeretesen végigkövette, az megér- 
demli, hogy megnézze a végeredményt: 





A cAsocidocsárticlestkmítna-xmi - száz áz 








Ele Et Vew Favortos Ted teb 








JE Done ZS TE Í KH mv comoster 





Mitől lett ez ilyen díszes és tarka (mi lesz ebből a szürke 
újságban?! :) ? Hát attól, hogy az XSL által generált HTML 
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kimenet kapott még egy CSS-t is a 8 -val megjelölt sorban. 
Anélkül csak egy fehér táblázatot látnánk. A teljesség ked- 


véért itt az na.css tartalma: 


LXxSTYLE2 

BODY 

( 
BACKGROUND-COLOR: snow 

, 

TABLE.OktatokTabla 

( 
BORDER-RIGHT: groove; 
BORDER-TOP: groove; 
BORDER-LEFT: groove; 
COLOR: mediumblue; 
BORDER-BOTTOM: groove; 
FONT-FAMILY: Tahoma; 


BACKGROUND-COLOR: lightgoldenrodyellow 


) 

TD 

ű 
BORDER-RIGHT: thin groove; 
BORDER-TOP: thin groove; 
BORDER-LEFT: thin groove; 
BORDER-BOTTOM: thin groove 

) 

£/STYLE2 


Az előbbi XSL transzformáció egy nagyon egyszerű példa volt, 
ennek ellenére már ez is elég átláthatatlan és bonyolult lett. Az 
XML technológia bonyodalmaiba akkor kóstolunk bele igazán, 
amikor az XSLT nyelvet kezdjük el használni. A gond az, hogy 
az XSLT nem procedurális nyelv, hanem alapvetően sablonok 
egyeztetésén alapul. Ez a fajta gondolkodás igen szokatlan egy 
Basic vagy C nyelven felnőtt programozónak. 

További nehézség, hogy mit tehetünk akkor, ha egy jó bo- 
nyolult XSLT transzformáció nem úgy működik, ahogy azt el- 
várjuk tőle? Nem formátumbeli hibákra gondolok, azt kiszű- 
rik a transzformáló komponensek. Akkor leszünk meleg hely- 
zetben, ha , csak" logikai hiba van az XSLT-nk működésében, 
és nem azt a transzformációt hajtja végre, amit mi módol- 
tunk ki. Ilyenkor jönnek képbe a nyomkövető vagy debugger 
programok, amelyek segítségével lépésenként lehet végre- 
hajtani a programunkat, ebben az esetben az XSL transzfor- 
mációt. Ez egy kemény feladat, de szerencsére az Activesta- 
te cégnek - amely elsősorban a Win32-es Perl eszközeiről hí- 
res - megjelent a Visual XSLT 1.0 [10] programja, ami egy 
plug-in a Visual Studio.NET 7-hez, és amelynek segítségével 
szerkeszthetjük és nyomkövethetjük az XSL transzformá- 
cióinkat. Szenzációs termék! A debugger ablakban láthatjuk 
a transzformáló XSLT-t, benne az éppen végrehajtás alatt ál- 
ló XSL paranccsal. A Watch ablakban láthatjuk a forrás XML 
éppen feldolgozás alatt álló elemeit, az Output window-ban 
pedig a transzformált végeredményt. 

A program jelenleg Beta 1 állapotban van, hasonlóan a Vi- 
sual Studio.NET 7-hez. Ennek ellenére aki komolyan, a jelen- 
ben és a jövőben élve szeretne XML-lel foglalkozni, minden- 
képpen szerezzen be egy példányt a Visual Studio.NET 7-ből, 
és töltse le a Visual XSLT 1.0-t. Mindkettő Must Have! 
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Újdonságok 

Az XML-t alkalmazó alkalmazásokat programozók legalapve- 
tőbb fegyvere a parser, XML értelmező, amely az XML Docu- 
ment Object Model-en keresztül programozottan elérhetővé 
teszi az XML dokumentumok belső szerkezetét. A parser-ek 
lehetővé teszik a felolvasandó XML dokumentumok ellenőr- 
zését egy megadott sémával szemben, amely jelen pillanat- 
ban - Microsoft-os platformon - DTD és XDR-el történhet. 
Az aktuális parser a Microsoft-tól a 3-as verziónál jár, ez az, 
amit éles környezetben is lehet használni. 

Azonban nincs megállás. Áprilisban a Microsoft kiadta a Mic- 
rosoft XML Parser (MSXML) 4.0 Technology Preview Release-t. 
Ezt még nem ajánlják produkciós környezetbe, de mindenkép- 
pen érdemes tanulmányozni. Miért? Azért, mert végre támo- 
gatja az XSD-t! A parser-ben implementált séma validáló kód 
a Wide Web Consortium (W3C) XML Schema, 2001. március 
30-ikai ajánlásában leírt módon működik, azaz olyan friss, 
hogy még meleg! Mivel ez még mindig nem a végleges XSD 
szabvány, így várható, hogy az valamennyit még változni fog 
a végleges kiadásig. Az XML parser 4 természetesen követni 
fogja a változásokat, újabb és újabb kiadásokkal. 

Mi van még a csomagban az XSD mellett? Megjelent benne 
egy új objektum, az MXHTMLWriter, amely segítségével a SAX 
API által felolvasott XML dokumentumból kapott adatfolya- 
mot lehet HTML-lé transzformálni. Ez egy alternatív megoldás 
lesz az XML --s XML DOM --s XSLT --s HTML feldolgozásra, ki- 
fejezetten nagyteljesítményű webalkalmazásokhoz. 

Az új verziót fel lehet telepíteni olyan gépre is, amin már 
van MSXML3-as parser, így az alkalmazáaok a verzió függő 
ProgID-k használatával tudják használni mind a 3-as, mind 
a 4-es változatot. Arra viszont vigyázzunk, hogy ne rakjuk 
fel produkciós szerverre, mert a verziófüggetlen objektum- 
létrehozást alkalmazó programok az új verzióból fognak egy 
példányt kapni, ami meglepetéseket okozhat. 


Zárszó 

Aki lelkiismeretesen végiglépkedett a példa XSL-en és XML-en, 
annak már van fogalma az XML alapú fejlesztések alapköveiről, 
látja a jéghegy csúcsát. De az igazi csemege még a víz alatt 
van. A következő számban a transzformációt már nem fogjuk az 
Internet Explorer-re bízni, hanem a kezünkbe vesszük az XML 
DOM-ot, és azzal hajttatjuk végre az XSL-ünket, mind kiszolgá- 
ló oldalon, mind ügyfél oldalon. És ha már ott vannak az ada- 
tok a böngészőben, miért ne lehetne rögtön szűrni illetve sor- 
barendezni őket, anélkül, hogy a szerverhez kellene fordulni.? 
Miért is ne? A júniusi számban megmutatom hogyan. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo onetacademia.net 


A cikkben szereplő URL-ek: 


[1]: DTD szabvány http://www.oasis-open.org/cover 

[2]: XDR szabvány http://www.ltg.ed.ac.uk/-ht/XMLData-Reduced.htm 
[3]: XSD http://www.w3.org/XML/Schema 

[4]: Példakódok http://technet.netacademia.net/feladatok/xml 


[5]: XML1.0 szabvány, magyarázattal! http://www.xml.com/axml/testaxml.htm 


[6]: CSS szabvány http://www.w3.org/Style/CSS 

[7]: XSL szabvány http://www.w3.org/Style/XSL 

[8]: XSLT szabvány http://www.w3.org/TR/xslt 

[9]: XPath szabvány http://www.w3.org/TR/xpath 

[10]: Visual XSLT 1.0 Beta 
http://www.activestate.com/ASPN/Downloads/VisualXSLT 
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XML-gessünk 


(V. rész), 


- szappanopera 


Bevezetés 

Sok időbe telik, mire a fejlesztők megegyeznek valamiben. 
Minden csoport hű az általa használt technológiákhoz, és 
nagyon nehezen vehető rá, hogy áttekintse a konkurens 
gyártók, technológia-diktátorok módszereit. S mi issza meg 
ennek a levét: a rendszerek együttműködési képessége. Lét- 
rejönnek alkalmazásszigetek a nagyvilágban, amelyek , há- 
zon belül" nagyon nyitottak, de a más típusú, önmagukban 
szintén nyitott rendszerekkel képtelenek kommunikálni. 
Lesz itt valaha megegyezés? Talán, igen. A kulcsszó: SOAP, 
Simple Object Access Protokol. 


Az elosztott alkalmazások kora 

Néhány éve még az volt a menő programozó, aki MFC-ben vagy 
Delphi-ben díszes, dokkolható és lebegtethető toolbar-okat és 
egyéb csicsás, lyukas és matyómintás ablakokat tudott létre- 
hozni. Azonban a világ változik. Amióta a számítógépeket 
összekötötték hálózati kábelekkel, azóta megvan a fejlesztők- 
ben és a megrendelőkben az igény, hogy olyan alkalmazásokat 
írjanak, amelyek több lóerővel működnek, azaz több számító- 
gép együttműködésével végzik el a feladatukat. Így a rendsze- 
rek nemcsak teljesítmény, de sokszor megbízhatósági előnyök- 
höz is jutnak, és mindezt sokszor olcsóbban, mint egy nagy 
böhöm vason megvalósított monolitikus társaik. 

Az elosztott alkalmazások igénye olyan technológiák kifej- 
lesztését követelte meg a nagy gyártóktól, amelyek elfedik 
a hálózati réteg bitfolyam jellegét, és a programozó számá- 
ra teljesen átlátszó módon képesek más gépen elhelyezke- 
dő programrészek, függvények meghívását biztosítani. Sőt, 
mivel a 90-es évek elején a hagyományos, moduláris progra- 
mozási paradigmát elhományosította az Objektum Orientált 
szoftverfejlesztés tana, a feljesztők olyan háttérinfratruktú- 
rára vágytak, amely objektumok vagy komponensek távoli 
létrehozását és kezelését biztosítja, számukra a lehető legegy- 
szerűbb és legtranszparensebb módon. 

Az igény megvolt, és a világ elindult a cél felé. Ahogy azt már 
megszokhattuk, a Microsoft elindult az egyik csapáson, és a 
UNIX-os világ is vágta a maga ösvényét, látszólag más irány- 
ba, a valóságban egymással párhuzamosan. A 80-as években 
két jelentősen elterjedt módszer volt a távoli eljáráshívásokra. 
Az egyik a Sun RPC (Remote Procedure Call, Távoli Eljáráshívás) , 
amelynek egyik legismertebb alkalmazása a UNIX rendszerek- 
ben elterjedt Network File System vagy ismertebb nevén NFS. 
A másik oldalon a Microsoft a DCE RPC-t használja még ma is 
a Windows-os, elsősorban NT alapú rendszerekben. 

Mindkét távoli eljáráshívási technológia működő, életképes, 
az évek során bizonyított, azonban nem objektumorientált. 
Mivel az 00P elvek keresztülverekedték magukat az egyete- 
mek vastag falain kívülre és a programozók fején belülre is, 
jogos volt az igény, hogy kellene valamilyen felsőbb réteg a 
RPC protokollok tetejére, amelyeken keresztül már objektumo- 
kat is rángathatunk a drót végén, nem csak globális függvé- 
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nyeket hívogathatunk. Megszülettek az ORPC protokollok, 
amelyek megpróbálták összebékíteni az objektumorientáltsá- 
got a hálózati protokollokkal. Ezt egyfajta cookie alkalmazá- 
sával oldották meg, azaz minden egyes kérésben elküldtek 
egy objektumazonosítót is a kiszolgáló folyamatnak, amely a 
saját adminisztrációs információiból tudta, hogy az ügyfél- 
program melyik objektumot akarja megszólítani. 

Egy tipikus ORPC kérés és válasz így néz ki: 


Objektum Végpont Azonosító 
(Melyik objektumot szólítjuk meg?) 
Interfészazonosító 
(Melyik interfészen van a keresett objektum?) 
Metódusazonosító 
(Melyik metódust kell meghívni?) 
Kiegészítő fejlécek 
(Mit felejtettünk ki a protokollból?) 
Paraméterblokk 
(Bemeneti és bemeneti-kimeneti paraméterek) 














Státuszkód 
(Sikeres volt a hívás?) 





Kiegészítő fejlécek 
(Mit felejtettünk ki a protokollból?) 
Paraméterblokk 
(Bemeneti és bemeneti-kimeneti paraméterek) 








Az Objektum Végpont Azonosító az előbb emlegetett cookie, 
amin keresztül a kiszolgáló tudja, melyik objektummal szeret- 
nénk foglalkozni. Az Interfészazonosító és a Metódusazonosító 
írja le a meghívni kívánt függvényt. A Kiegészítő fejlécek szol- 
gálnak olyan bővítések későbbi becsempészésére, amelyek még 
nem ismertek a protokoll kifejlesztésekor. A Paraméterblokkok 
célja nyilvánvalóan a metódusok paramétereinek szállítása. 
Manapság két jelentős ORPC implementáció virágzik: a Micro- 
soft részéről a DCOM (Distributed Component Object Model) , a 
UNIX-os világban pedig az Internet Inter-ORB Protokol, rövi- 
den IIOP, mely a CORBA protokollja. Mindkettő nagyjából a 
fenti struktúrákat használja a végpont azonosítására, de ter- 
mészetesen a konkrét mezők neve és száma különbözik. 
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Mindkét protokollban ki kellett dolgozni a paraméterek átalaki- 
tását byte-folyammá, majd vissza az eredeti jelentésükké 
(Stringgé, Integerré, satöbbi). Ezt az oda-vissza alakítást hívják 
Serialization-nek illetve Deserialization-nek. Érdemes a szava- 
kat megjegyezni, mert a .NET kapcsán sokszor fogunk még ró- 
luk hallani. A DCOM az ún. Network Data Representation (NDR) 
formátúmot használja, a IIOP Common Data Representation-t. 
A két formátum hasonló, de azért annyira különböznek, hogy a 
kétféle rendszer nem tud szót érteni egymással. 


Miért nincs egységes protokoll? 

Miért van az, hogy a világ egyik pólusa DCOM-on, a másik 
CORBA-n keresztül kommunikál? Mindkét protokoll hozzá 
van láncolva az őt kidolgozó céghez. Létezik ugyan DCOM 
implementáció UNIX-okra, de alig -ha egyáltalán- használ- 
ják őket. Sajnos az a helyzet, hogy a DCOM annyira hozzá 
van gyógyítva a Windows NT háttérinfrastruktúrájához, 
hogy nehéz bármilyen más platformon teljes hatékonyságá- 
ban kihasználni. A CORBA már sokkal több rendszeren imp- 
lementált, ám a különböző megvalósítások között is vannak 
olyan apró részletkülönbségek, amely miatt csak alapszin- 
ten működik jól az együttműködés, és - hasonlóan a DCOM- 
hoz - pont a finomságoknál (tranzakciók, biztonság) lesz- 
nek gondok a heterogén rendszerek együttműködésében. 
Mindkét technológia jól működik zárt, jól adminisztrálható 
belső rendszerben, leginkább cégen belüli kiszolgálók közöt- 
ti kommunikációra. Azonban mindketten megbuknak, ha be- 
jönnek a képbe a tűzfalak és az Internet. Márpedig ha tet- 
szik, ha nem, bejöttek. A mai rendszereknél egyre fokozódó 
igény van az összetevők Interneten keresztüli elérhetőségé- 
re. Annak az esélye, hogy a DCOM-hoz szükséges számtalan 
RPC portot kinyissa egy ,tűzfalgazda", közelít a nullához. 
Melyik az a port, amely még a legtöbb cégnél nyitva van? 
Igen, a 80-as, amely a webböngészéshez szükséges. Akkor 
miért nem lehet egy olyan réteget fejleszteni a DCOM illetve 
a CORBA fölé, amely a VPN-hez hasonló módon egy csatorná- 
ra tereli a teljes protokoll adatforgalmát? Például a HTTP pro- 
tokollra, amit olyan szívesen átengednek a tűzfalak. 

Ezek a technológiák léteznek, például Windows 2000-ben a 
DCOM-hoz COM Internet Services Proxy néven létezik egy kie- 
gészítés, ami rá tudja ültetni az DCOM-ot HTTP protokollra. 
Azonban ettől még nem fog kommunikálni a világ két ORPC 
rendszere, nem beszélve a konfigurációs bonyodalmakról... 


A HTTP, mint egy jobb RPC 

Miért pont HTTP? A HTTP-t hasonlóan az RPC-hez nagyon so- 
kan használják, egyszerű, és ellentétben az RPC-vel a legtöbb 
tűzfal szívesen átengedi magán. A HTTP kéréseket általában 
webkiszolgálók fogadják, és legtöbbször rajtuk keresztül induló 
kiegészítő alkalmazások dolgozzák fel (pl. CGI alkalmazások) . 
A DCOM-hoz és az IIOP-hez hasonlóan a HTTP is kérés-vá- 
lasz típusú protokoll. Az ügyfélprogram egy megadott TCP 
porton hozzákapcsolódik a HTTP szerverhez, amely általá- 
ban a 80-as porton figyel. Miután a TCP csatorna felépült, 
az ügyfélprogram elküldi a kérését, azt a kiszolgáló értel- 
mezi, feldolgozza, és visszaküld egy választ. A teljes kom- 
munikáció nyelvezetét a HTTP protokoll írja le. 

A következő kódrészlet egy egyszerű HTTP kérés: 
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POST /szappan HTTP/1.1 
Host: 172.16.0.200 
Content-Type: text/plain 
Content-Length: 11 


NetAcademia 


Látható, hogy a kérés szöveges formátumú, ami hibakeresésnél 
igen nagy segítség, hisz például Network Monitorral könnyedén 
visszafejthető a HTTP kommunikáció (ugye, ugye? — a szerk). 
Az első sor három elemet is tartalmaz: a HTTP metódust 
(POST), a kért URI-t (/szappan), és a protokoll verzióját 
(HTTP/1.1). A metódus a HTTP (és WebDAV) szabványban 
rögzített értékeket vehet fel, a példában szereplő POST-ot ál- 
talában akkor használjuk, ha a webkiszolgáló felé valamilyen 
információt szeretnénk eljuttatni. Ez a hagyományos webfej- 
lesztésben például egy kitöltött form adatait jeletheti. 

Az URI azonosítja a célobjektumot. Közönséges webszerve- 
IIOP hasonlattal élve az elérni kívánt objektum azonosítója. 
A harmadik és a negyedik sor a kiszolgálónak küldött tarta- 
lom típusát és hosszát azonosítja. A típus segítségével tudja 
az ügyfélalkalmazás a kiszolgáló tudtára adni az általa hasz- 
nált tartalomleíró nyelvezetet. DCOM-nál ez az NDR. HTTP-nél 
általában text/plain, ami közönséges ASCII szöveget jelent, 
vagy text/html, ami a HTML kódolt tartalmat jelenti. 

Mivel a HTTP fejléc hossza kérésenként más és más lehet, 
az utolsó fejléc után két kocsivissza-soremelés karakter is 
van, innen tudja a feldolgozó alkalmazás, hogy hol végző- 
dik a fejléc-blokk, és hol kezdődnek a valódi adatok, mely- 
nek hosszát és kódolását a Content-Length és Content-Type 
fejlécek azonosítják. Példánkban a tartalom (payload) 
hossza 11 byte, és tartalma NetAcademia. 

Miután a webkiszolgáló feldolgozta a kérést, visszaküld egy 
választ az ügyfélalkalmazásnak. A válasznak kötelezően tar- 
talmazni kell egy sikerességet jelző kódot, és ha akar, ak- 
kor a kéréshez hasonlóan további tartalmat is szállíthat. 


200 OK 
Content-Type: text/plain 
Content-Length: 12 


aimedacAteN 


A 200-as státuszkód a szabványos sikerességet jelző kód a 
HTTP protokollban. Az érdeklődők a teljes HTTP 1.1 szab- 
ványt a 2616-os RFC-ben találhatják meg a [1] címen. 


Az XML, mint egy jobb NDR 

Láttuk, hogy a HTTP protokoll nagyban kiválthatja az RPC-t, 
azonban van egy funkció, ami hiányzik belőle: a távoli me- 
tódushívások paramétereinek szabványos leírása. És itt jön 
a képbe az XML. 

Hasonlóan az NDR-hez és a CDR-hez, az XML is egy adatle- 
író protokoll, amely ráadásul szabványos és platformfügget- 
len is. Segítségével könnyedén átalakíthatjuk a paraméte- 
reket ASCII adatfolyammá (Serialization), amelyet könnye- 
dén lehet hálózaton átvinni, és a céloldalon dekódolni 
(Deserialization). Igen előnyös tulajdonsága, hogy szinte 
az összes platformon bőséges a támogatottsága, szöveges 
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alapú, így egyszerű eszközökkel is könnyű feldolgozni, és 
nagyon könnyű egy már meglévő XML alapú formátumot 
egyértelmű módon kibővíteni. (Remélem cikksorozatunk 
rendszeres olvasóinak már kigyúlt az agyában a NameSpace 
fogalom lámpása, mint a bővíthetőség záloga.) 

A paraméterek struktúrájának leírására is már van kész esz- 
közünk (2001. április óta), amely nem más, mint az XML 
Schema. Az alábbi részlet egy olyan XML dokumentumot ír 
le, amelyben az elemek az urn:schemas-netacademia- 
net:SztringKolbaszolas névtérben laknak, a gyökérelem ne- 
ve HatraArc, aminek kötelezően van egy gyermekeleme mit 
néven, annak tartalma string típusú, és mögötte lehet még 
akárhány darab és típusú további elem. 


Scschema 
xmlnsz"http://www.w3.org/2001/XMLSchema" 
targetNamespace- " urn: schemas-netacademia- 

4 net:SztringKolbaszolas "2 
ccomplexType name-"HatraArc"5 

Sseguences 
delement namez"mit" typez"string" /5 
Lany minOccursz!o! 
maxOccursz! unbounded " 
processContentsz"skip" /5 
£/seguence 5 
£/complexType2 


£/schemaz 


Azaz látható, hogy a mai állás szerint van egy adatrepre- 
zentációs szabványunk (XML [2]), és típus (struktúra) leí- 
ró szabványunk (XSD [3]). Mi akadálya ezekkel kiváltani az 
NDR-t és társait? Semmi! Helló SOAP! 


HTTP -- XML - SOAP 

A SOAP szabvány nem tesz mást, mint összefogja az XML-t, 
mint a paraméterek kódolási szabványát és a HTTP-t, mint 
adatátviteli mechanizmust. Egy SOAP metódushívás nem 
más, mint egy egyszerű HTTP kérés és arra adott válasz, 
amelyben a kérés és válasz fejlécei, és azok tartalma meg- 
felel a SOAP szabványban előírtaknak. Ennyi az egész. A 
SOAP szabvány nem szól semmit arról, hogy a webszerve- 
ren mit történjék egy SOAP formátumú HTTP kérés hatásá- 
ra. Nem írja elő, hogy ettől egy COM objektumra képződ- 
jön le a kérés, egy sima DLL-nek hívjanak meg egy függvé- 
nyét, egy PERL modul álljon a kiszolgálás legvégén, vagy 
éppen egy WebSzerviz legyen a kiszolgáló. Bizony-bizony, 
a WebSzervizek hátterét kőkeményen a SOAP adja. Mi más? 
A SOAP kérés tulajdonképpen egy HTTP POST kérés. A Con- 
tent-type kötelezően text/xml. A Reguest-URI természete- 
sen kötelező, hisz ez azonosítja, hogy milyen objektumot 
vagy szolgáltatást akarunk meghívni a kiszolgálón. A HTTP 
kérésben kötelezően benne kell lenni egy fejlécnek, ami a 
meghívandó metódus nevét tartalmazza. E fejléc neve 
SOAPMethodName, és a tartalma a meghívni kívánt metó- 
dus neve egy URI-val megelőlegezve: 


SOAPMethodName: urn:schemas-netacademia- 


4  net:SztringKolbaszolastHatraArc 
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Azaz szeretnénk meghívni a HatraArc metódust a urn: 
schemas-netacademia-net:SztringKolbaszolas névtérben. A 
névtér szerepe pont ugyanaz, mint DCOM-ban az interfész- 
azonosító. Felfoghatjuk úgy is, hogy a kettő együtt azono- 
sít egyértelműen egy metódust. 

A SOAPMethodName fejléccel tudatjuk a kiszolgálóval, 
hogy melyik metódust kívánjuk meghívni. A paraméterek a 
HTTP kérés törzsében utaznak, és a kódolásukra speciális 
SOAP szabályok vonatkoznak. Mik ezek? A paramétereket 
egy Envelope elembe, és azon belül egy Body elembe kell 
foglalni. A Body-n belül kell lenni a metódus nevét tartal- 
mazó gyermekelemnek, melynek a SOAPMethodName fej- 
lécben a metódus nevét megelőző névtérben kell lenni. 


POST /szappan/Amo HTTP/1.1 

Host: 172.16.0.200 

Content-Type: text/xml 

Content-Length: 163 

SOAPMethodName: urn:schemas-netacademia-net: 


4  SztringKolbaszolasítHatraArc 


SEnvelope? 
cBodyz 
Xna:HatraArc 
xmlns:na-! urn:schemas-netacademia-net : 
4 SztringKolbaszolas"5 
cmitosNetAcademiac/mit: 
£/na:HatraArc5 
€/Body? 


£/Envelope? 


A SOAPMethodName-ben található metódusnévnek egzaktul 
egyezni kell a Body gyermekelemével (a névteret is beleért- 
ve), ellenkező esetben a fogadóalkalmazásnak meg kell ta- 
gadni a kérés kiszolgálását. Ez egy zseniális húzás, melynek 
segítségével a tűzfaladminisztrátorok anélkül tudják szabá- 
lyozni, hogy mely metódusokat hívhatnak meg a tűzfalon ke- 
resztül, hogy a tűzfalnak bele kellene nézni a kérés tartalmá- 
ba! Így nem kell kiegészíteni a tűzfalak alkalmazásszintű 
protokollszűrőit, mert a HTTP fejlécek szűrése minden komo- 
lyabb tűzfalba be van építve, és paraméterezhető. Emellett 
egy fejléc sokkal rövidebb lehet, mint a tényleges tartalom 
(gondoljuk például egy többezer elemű tömbparaméterre) , így 
a szűrés során nem kell nagy XML adattömegeket elemezget- 
ni, ami igencsak lefoglalná a tűzfalak processzorát. 

A SOAP válasz nagyon hasonló szerkezetű a kéréshez. A kime- 
neti vagy kétirányú paraméterek most is az Envelope/Body 
elemek vendégei, és az őket befoglaló elem neve a hívott me- 
tódus nevéből képződik egy "Response" utótaggal kiegészítve. 


200 OK 
Content-Type: text/xml 
Content-Length: 181 


SEnvelopes 
cBody? 
Zna:HatraArcResponse xmlns:naz!urn: 
4  schemas-netacademia-net:SztringKolbaszolas "5 
SresultsaimedacAteNc/result5 


£/na:HatraArcResponse? 
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£/Envelope? 


Láthatjuk a szabványos HTTP státuszkódot (sikeres kiszolgá- 
lás - 200), és a borítékba zárt választ, amely ugyanabban a 
névtérben van, mint a kérés. A SOAPMethodName fejlécre 
most nincs szükség, ezért nincs is jelen. 

Ami elsőre furcsa, hogy a szabvány egy szót sem szól arról, 
hogy mi történjen a szerveren a kérés hatására. Az IIS pél- 
dául képes közvetlenül SOAP kérésekre válaszolni? Termé- 
szetesen nem, mint ahogy más webszerverek sem. De mind- 
egyiket könnyű kiegészíteni olyan módon, hogy alkalmas 
legyen erre. Windows 200x platformon a hamarosan végle- 
ges állapotúvá érő .NET Framework az, ami Microsoftos kör- 
nyezetben a legkényelmesebb hátteret biztosítja SOAP ki- 
szolgálók írására. Az, hogy történetesen a Microsoft föléhú- 
zott egy absztrakciós réteget, amit WebSzerviznek hívnak, 
senkit ne zavarjon meg. Amikor WebSzervizeket írunk .asmx 
kiterjesztésű fájlokban, akkor tulajdonképpen egy SOAP ki- 
szolgálót implementálunk. A .asmx lapnak SOAP formátumú 
kéréseket küldve ő nagyszerűen fog válaszolni, és a lapban 
implementált osztályok metódusait játszi könnyedséggel 
elérhetjük. Szerencsére a Microsoft egy lépéssel tovább- 
ment, és nekünk még csak nem is kell törődni a ,csúnya" 
SOAP fejlécek és tartalom írásával, illetve a válasz elemzé- 
sével. Egy wsdl.exe nevű kis eszköz legyárt nekünk egy (C4, 
VB, JScript) forrásnyelvű .NET assembly-t, ami egy olyan 
osztály leírását tartalmazza, amely pontosan azon metódu- 
sokat tartalmazza, amiket a SOAP szerverünk (WebSzerviz) 
számunkra felkínál. A generált osztály mögött egy 
SoapHttpClientProtocol nevű osztály áll, ami magábazárja a 
SOAP protokoll által előírt összes részletet. Ami külön jó, 
hogy mi még ezzel sem kell, hogy érintkezzünk, mi csak ka- 
punk egy osztályt, amelynek metódusait meghívva egy tá- 
voli osztály aktiválódik, annak meghívódik az azonos nevű 
metódusa, a paraméterek jönnek-mennek (és nem csak egy- 
szerű integerek és társaik, hanem akár komplett osztályok 
is!), és az egészből semmit nem látunk ügyféloldalon. Sőt, 
még kiszolgálóoldalon sem! De ez már egy másik történet, 
amelyről még sokat fognak hallani Kedves Olvasóink. Kösz 
SOAP, kösz .NET framework! 


Hogyan lássunk neki? 

Remélem sikerült felcsigáznom a SOAP iránti érdeklődésü- 
ket, és már alig várják, hogy kipróbálhassák valami kis pél- 
daprogramon a technológiát. Milyen lehetőségeink vannak 
a kezdésre ügyfél és kiszolgálóoldalon? 

Kezdjük az ügyféloldallal. A Microsoft Interactive Developer 
2000. januári számában Aaron Skonnard publikált egy cik- 
ket SOAP: The Simple Object Access Protocol címmel. A cikk 
megtalálható az MSDN library-ban is. Áron írt egy nagysze- 
rű SOAP teszt ügyfélalkalmazást Internet Explorer 5-re. A 
cikkhez — mellékelt  önkicsomagoló állományban a 
default.htm-et megnyitva indul el a SOAP teszter alkalma- 
zás. A megadott SOAP szerver-végpont és metódusnév meg- 
adása után a Call Method gomb megnyomására induló függ- 
vény összeállítja a SOAP kérést, és az XMLHTTP objektum 
segítségével elküldi a kérést a SOAP kiszolgálónak. A kérést 
is és a kapott választ is megtekinthetjük a lap ablakaiban. 
Az alkamazás letölthető a [4] címről is. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
LINUX KÜLÖNSZÁM 


SZAPPANOPERA 





ÁLIES Generic SOAP Client - Microsoft Internet Explorer 


] Ele Edt View  Favorítes Iools Help 
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Enter SOAP Reguest í 


Either choose one of the pre-configured test endpoints or manually enter 
the SOAP reguest data below. 





























Test-Endpoints: [show descriptions] 
http./soap.develop com/soapdemo/session asp (Translate) . 











Endpoint: 

http./so8p.develop.com/sospdemo/session.asp 

Interface: 

s0ap:cdi:com.develop.sospdemo V8SoapSrv. VBSoapTest 

Method: 

fTranstate 

Payload (XML): 

jcTrai atercp a 
jeypes"soap:cdl1:com. develop . soapdemo. VBSOoapSrv.point"2cx 
jeypes"i4":200€£/x2€y typer"i4"5500£/y2c/p:c/Translatez 




















T Use M-POST (othervrise regular POST) 


Call Method ] Clear Input Fields. 








SOAP Results 


Original SOAP Reguest 


Reguest Headers 
[PosT nttp://soap.develop.com/soapdemo/session.asp  HTTP/1.1  ] -] 


R1Done TETT mv Comouter 





Zárszó 

Nem beszéltem a másik oldalról, a SOAP kiszolgálókról. A 
témakör megér még (minimum) egy misét, így azzal a kö- 
vetkező részben fogok foglalkozni. Megnézzük a SOAP Tool- 
kit szolgáltatásait is, és írunk egy VB alapú és egy PERL ala- 
pú SOAP kiszolgálót IIS5 alá. Akinek van kedve, az akár egy 
Linux-os gépen is megírhatja a kiszolgálókomponenseket 
Apache, vagy egyéb http daemon alá is, köszönhetően a 
PERL hordozhatóságának. Hol van már a ,a Windowsos prog- 
ramok csak Windwosos progamokkal működnek együtt" vi- 
lág! A múltban, igen nagy örömünkre. 


Írta és rendezte: Soczó Zsolt 
Zsolt.Soczo(onetacademia.net 


LAS LTJ EZ AGA 


[11]: RFC2616 
http://www.w3.org/Protocols/rfc2616/rfc2616.html 
[2]: XML szabvány 
http://www.w3.org/TR/2000/REC-xml-20001006 
[3]: XML Schema 
http://www.w3.org/TR/xmlschema-0O 
[4]: Letölthető kódok 
http://technet.netacademia.net/download/xml 
[5]: SOAP szabvány 
http://www.w3.org/TR/SOAP 
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MIME - levelezés 


az interneten 


(III. rész) 


Az elmúlt két számban megismerkedtünk a MIME üzenetek 
néhány fontos tulajdonságával. Tudjuk, milyen korlátokat 
szab az SMTP protokoll, ismerjük a MIME karakterkészletekre 
és tartalomtípusokra vonatkozó bővítményeit; most végre kö- 
vetkezhetnek a több részből álló üzenetek, amelyek a MIME 
igazi erejét adják. Az egyes RFC-k címét nem írjuk le, min- 
den RFC ugyanúgy, az [1] módon leírt címmel érhető el. 


A MIME Browser 

Aki Windows 2000 operációs rendszerrel rendelkezik, a [2] 
címről letöltheti a MIME Browser nevű programocskát, ami MI- 
ME formátumú levelek tartalmának vizsgálatára használható 
demonstrációs eszköz. A telepítés után futtassuk a program- 
könyvtárban található regshell.vbs scriptet, ekkor az .eml fájlok 
(elmentett MIME formátumú levelek) kiugró menüjében megje- 
lenik a ,Browse MIME Structure" menüpont, amire kattintva 
elindul a MIME Browser, és megkísérli betölteni az adott állo- 
mányt. A cikk olvasása során ez az eszköz folyamatosan nagy 
segítséget nyújt majd a levélformátumok megértésében, el- 
lenőrzésében. Annak sem kell izgulnia, aki Windows 2000 híján 
nem tudja használni a programot, mert az újság hasábjain áb- 
rákkal megpróbáljuk szemléltetni a látnivalókat. Ugyaninnen, a 
[2] címről lehet letölteni a cikkben található példa-leveleket 
is, amelyeket bárki - még a MIME Browser hiányában is — ki- 
próbálhat. Az .eml fájlokra kettőt kattintva az alapértelmezett 
levelezőprogram megjeleníti a levél tartalmát, ha pedig Note- 
Pad-del megnyitjuk őket, tanulmányozhatjuk a forráskódjukat. 


Több részből álló üzenetek 

A MIME üzenet több részből is állhat. Az SMTP szabvány szem- 
pontjából persze továbbra is egyetlen, csupaszöveg állomány- 
ról van szó, a levél részekre bontását a szövegben található 
határolókarakterek (vagy inkább ,,határolómondat") segítik. 
Egy nagyon egyszerű, mindössze két szöveges részt tartalmazó 
MIME levél egyszerűsített forráskódja így néz ki (1.em0): 


From: Fulop Miklos Ccmickénetacademia.net5 
MIME-Version: 1.0 
Content-Type: multipart/mixed; 


boundary-"hatarolo-szoveg-0001" 


Ez egy magyarazo szoveg nem MIME programok 


reszere. Ha ezt latja, ideje haladni a korral! 


--hatarolo-szoveg-0001 


Content-Type: text/plain 
Ez az elso resz torzse 


--hatarolo-szoveg-0001 


Content-Type: text/plain 
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Ez a masodik resz torzse sg 
--hatarolo-szoveg-0001-- a [3 
Ez az üzenet a demonstrációt leszámítva semmire sem hasz- 
nálható, mert itt csak a MIME megértéséhez szükséges fejléce- 
ket tüntettük fel. A szokásos és elhagyhatatlan ,,MIME-Versi- 
on" fejléc mellett feltűnik egy eddig ismeretlen tartalomtípus- 
főcsoport (Content-Type), ez pedig a multipart. Ez a tartalom- 
típus jelzi a program számára, hogy az üzenet tartalma több 
részből áll, azt fel kell darabolni és egyenként, mint üzenetré- 
szeket (angolul bodypart) kezelni. Az üzenetrészekről még ké- 
sőbb szólunk, előbb lessük meg a darabolás módját: A Con- 
tent-Type fejlécnek van egy boundary paramétere (esetünkben 
ennek értéke , hatarolo-szoveg-0001"). Ahol ez a szöveg feltű- 
nik az üzenetben (mindig egy sorban, két mínuszjel után, lásd 
0), ott képzeletben fogjunk egy ollót, és nyisszantsuk el a 
szöveget. A legelső előfordulás előtti részt (2) mi, MIME-ul 
tudók eldobjuk. Aki viszont nem ismeri a MIME-ot, annak ez 
fog legelőször megjelenni, ezért ez a hely ideális a régebbi le- 
velezőprogramoknak szóló kedves üzenet elhelyezésére. A 
több (nem feltétlenül két-) részből álló üzenet utolsó részének 
végén található határolószöveg annyiban különbözik a többi- 
től, hogy annak a végén is találunk két mínuszjelet (0). 


CESHZTEET 8 z]DI21 














multipart/mixed . (charset. : encoding: 7bR: size: 589 1002) 
(5) text/plain. (charset: is0-8859-2: encoding: 7bit; size: 109" 1929 
(új) text/plain (charset: ; encoding: 7bit; size: 120 7 2029 


[From Fulop Miklos cmick(önetacademia net 

IMIME:Versiort 1.0 

Cortent-Type: mukipart/mixed; 
boundatya" hatarolo-szoveg 0001" 







5 A levél a MIME Browserben. Jól látszik, hogy a levél 
két részből áll; és a részek text/plain típusúak 


Az üzenetrészek 

A szétszabdalt üzenet részei külön-külön egy-egy igazi, 
Nagy" SMTP levélhez hasonlítanak. Mindegyik üzenetrész 
(bodypart) fejrészt (fejléceket) és törzset tartalmaz, a két 
fő összetevőt pedig egy üres sor választja el. Az üzenet- 
rész fejlécei között most persze nem a teljes levélre, csak 
az adott üzenetrészre vonatkozó MIME-fejlécek találhatók 
(tartalomtípus, karakterkészlet, kódolás, stb.). Miután min- 
den üzenetrész saját fejlécekkel rendelkezik, semmi akadá- 
lya annak, hogy az üzenet egyik része mondjuk cirill betűs 
szöveg, a másik pedig mondjuk egy magyar nyelvű HTML 
dokumentum legyen. Sőt! Az üzenetrész önmaga is lehet 
egy több részből álló (multipart) üzenetrész, saját, egyedi 
határolószöveggel - ilyenkor fogjuk a kisollót, és az üze- 
netrészt tovább daraboljuk. Akármilyen bonyolult MIME-fát 
építhetünk, álljon itt egy valóságból kölcsönzött, bár nem 
az egyszerűbbek közül való példa (2.eml): 
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B— Ég multipatt/mixed . (charset: ; encodíng: 7bit; size: 73465 " 9429 
Er— Ég mulipatt/related  (charset : encoding: 7bit: size: 46460 — 592) 
A— -Ég mulipatt/altematíve  (charset: : encoding: 7bit: size: 10737 127 
(ÉJ texvolain. (charset iz0:8859-2: encodíng: guoled-printable; size: 144 7 0) 
1——€g] text/html. (charset: is0-8959-2; encoding: guoted-piintable; size: 6457 129 
(HI imagz/peg (charset : encodíng: base64; size: 45121 7 582) 
) applicaion/msword  (charzet ; encodíng: base64; size: 26774 342) 
—A appícation/xpkcs7-signature . (charzet ; encodíng: baseS4; size: 41057 52) 
5 HTML formátumú, beágyazott képet és egy Word csa- 
tolt állományt tartalmazó, végül digitálisan aláírt levél 


felépítése 


Gyakorlatlanok ne próbálják az ábrát rögtön, részletekbe 
menően megérteni - a migrén fájdalmas lehet, és ráadásul 
lassan is múlik el, - egyelőre a hierarchiát próbáljuk meg 
átlátni. Figyeljük meg a négy egymásba ágyazott multipart 
üzenetrészt, és azt, hogy ki kinek a gyermeke. A második 
sszinten" található multipart/mixed üzenetrész például 
egy Word dokumentumot és másik multipart üzenetrészt 
tartalmaz, ami egy újabb multipart-ból és egy JPEG képből 
áll - és ez még csak a hierarchia fele! 


Üzenetrész-fejlécek 

A multipart tartalomtípus is ,csak" egy főcsoport, és ennek a 
főcsoportnak is több alcsoportja létezik. Mielőtt azonban a 
multipart-alcsoportokra rátérnénk, bemutatjuk a leggyako- 
ribb, multipart-alcsoporttól függetlenül használt fejléceket. 


A Content-Type üzenetrész-fejléc 

Ez talán a legfontosabb információ: az üzenetrész által hordo- 
zott adat típusát határozza meg (ami ugye lehet valamelyik 
hagyományos, az előző számban már bemutatott tartalomtí- 
pus, vagy akár egy másik multipart üzenetrész is). Szöveges 
tartalomtípus esetén a legtöbb esetben ez a fejléc rejti az 
üzenetrészben használt kódtábla azonosítóját (charset): 


Content-Type: text/plain; 
charset-"iso-8859-2" 


A name paraméterben pedig gyakran hordozza az üzenet- 
rész által tartalmazott fájl eredeti nevét, például: 


Content-Type: application/msword; 


name-"doci.doc" 


Végül ne feledkezzünk el arról, hogy a multipart tartalom- 
típus esetén itt kell megadnunk a darabolás helyét jelző 
szöveget (boundary): 


Content-Type: multipart/mixed; 
boundary-"hatarolo-szoveg-0001" 


A Content-Type fejlécnek e háromnál sokkal többféle para- 
métere lehet, ezeket a paramétereket mindig maga a tarta- 
lomtípus határozza meg. A különböző multipart tartalomtí- 
pusok paramétereiről a megfelelő helyen mi is említést te- 
szünk, egyéb esetben az RFC-k böngészése segíthet. 


A Content-Transfer-Encoding üzenetrész-fejléc 
Csakúgy, mint a teljes üzenetre vonatkozóan (lásd a teljes 
leírást az előző számban), üzenetrész-fejlécként használva 
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is az üzenetrész-tartalom 7 bitre kódolásához használt 
módszert jelzi. Üzenetrészenként használva megoldható, 
hogy az üzenet szöveges részeit a Ouoted-Printable, míg a 
bináris részeket (mondjuk egy csatolt word dokumentumot) 
az ilyen tartalomnál hatékonyabb Base64 kódolással vi- 
gyük át. Fut még a 7bit kódolás is, ami a nemkódolást je- 
lenti (ASCII szöveg esetén). Példák: 
Content-Transfer-Encoding: guoted-printable 
Content-Transfer-Encoding: base64 


Content-Transfer-Encoding: 7bit 


A Content-Disposition üzenetrész-fejléc 

No, ez a fejléc már teljesen új. Az üzenetrészre aggatott Con- 
tent-Disposition fejléc jelzi, hogy az egy csatolt állomány (ez 
esetben értéke attachment), vagy a levélben valahol felhasz- 
nált komponens (ilyenkor inline). Az inline típusú üzenetrészt 
a levelezőprogramok elvileg nem jelenítik meg, mint csatol- 
mányt. Próbáljuk csak ki, nyissuk meg a 3.eml példát! A leve- 
lezőprogram a három üzenetrészből az elsőt, a levél törzsét 
megjeleníti; a másodikat csatolt fájlként jelzi (kattintással 
megnyithatjuk, ha akarjuk), míg a harmadik ismét, felhaszná- 
lói közbeavatkozás nélkül látható (hiszen ,, része" az üzenet- 
nek). Ha a Content-Disposition értéke attachment, akkor a fájl 
későbbi kezelésére vonatkozó információs paramétereket is 
tartalmazhat: mindenekelőtt a fájl nevét (filename), esetleg a 
méretét, vagy a létrehozásának dátumát, például: 


Content-Disposition: attachment; 


filename-z"1.txt" 


Ebből tudja a levelezőprogram, mi volt a csatolt fájl 
eredeti neve. Ha ez a paraméter hiányzik, a program 
kénytelen a hasára csapni; ilyenkor kapunk ilyen fájlne- 
veket, hogy: att00891.txt vagy hogy att00915.gif. 

Hogy a kiterjesztést honnan tudja mégis? Ennek meg- 
fejtése házi feladat! 


Nos körülbelül ennyit az általános üzenetrész-fejlécekről. A 
továbbiakban a különféle multipart-tartalomtípusokról, és — 
az általuk használt, speciális üzenetrész-fejlécekről érteke- 
zünk. Mielőtt beleugranánk a mélyvízbe, ellenőrizzük az ál- 
talános üzenetrész-fejlécekről összegyűjtött tudásunkat a 
4.eml példa segítségével! 





ISTEN EN k4 
Fin Vegy Aba: 
fég mullipaít mixed . fcharzet: : encoding: 7ba; size: 2055 7 1002) 

(a) teatélőn. fcharset iro 8855.2: encvdngi 752: size 124" 61) 
fű) temolán feharset : encvdng avotedpintable: sre: 225 1139) 
[a 1249-6I3) 








From: Fulop Miklos 
Date: 2001. június 11. 2304 
To: Fulop Milos 
Subject:  Contert-Type teszt 









Ez egy egyszeru, szoveges ASCII torzs 








a Egyszerű, csatolt fájlokat tartalmazó levél -— figyel- 
jük meg az üzenetrészeknél használt különféle kódolási 
módszereket (encoding) 
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SZABVÁNYOK MIME — 
A multipart-alcsoportok 

Futólag már említettük, hogy a multipart tartalomtípus-fő- 
csoport különféle alcsoportokat tartalmaz. Az rendben van, 
hogy az üzenet több részből áll, de van-e a részeknek vala- 
mi közük egymáshoz? Az alcsoport szerepe, hogy megjelöl- 
je az általa tartalmazott üzenetrészek egymáshoz való vi- 
szonyát. Mindegyik tartalomtípusnak különleges szerepe 
van, és a legtöbb saját üzenetrész-fejléceket is használ. 


A multipart/mixed tartalomtípus 

A legáltalánosabb, legegyszerűbb és talán leggyakoribb típus 
(RFC 1521). A részeknek nincs szorosabb közük egymáshoz, 
hacsak nem az, hogy egy üzenetbe kerültek. Tipikus példa az 
egyszerű, csatolt állományokat tartalmazó üzenet (mint az 
eddigi példák többsége, például a legutolsó 4.eml is). 


A multipart/alternative tartalomtípus 

Ez egy nagyon érdekes típus (RFC 1521); szerepe a HTML 
levelek megjelenésével vált egyre fontosabbá. Az alterna- 
tív üzenetrészek ugyanazt tartalmazzák, különböző formá- 
tumban; közülük elég azt megjelenítenünk, ami a szívünk- 
nek kedves. Lássuk csak egy egyszerű, tisztán szöveget 
tartalmazó, de HTML levél felépítését (5.eml): 


CEISEZTESE EE] T E 


File View About... 









mullipart/atematíve . charset: : encoding: 7bit; size: 11. 
(E) text/plain (charst 
E] text/himi  (charset: iso:8859-2; encoding: guotediprintable; size: 470 7 427) 





a HTML levél, text alternatívával 


Egy jólnevelt HTML levél egy text/plain és egy text/html részt 
tartalmaz, ahol a text/plain üzenetrész a HTML rész szöveges 
kivonatát tartalmazza. Mi dönthetünk: ha nem akarjuk a 
HTML-t megjeleníteni, ott a szöveges verzió. Ez persze azt je- 
lenti, hogy a levél tartalma redundáns, viszont levelezőprog- 
ram-barát. Látható, hogy az üzenet teljes terjedelmének 
429o-át a HTML üzenetrész teszi ki, a plusz szöveges rész csak 
további 1099 (a 100-ból fennmaradó részt a levél SMTP fejlécei 
képezik; ez az arány persze levelenként eltérő). A többlet ter- 
helés tehát jelen van, de általában nem számottevő. 

Fontos megjegyezni, hogy az alternatív tartalomtípus sem csak 
két verziót tartalmazhat; előfordulhat akár egy text-rtf-word6- 
word2000 csomag is. Az RFC 1521 mindössze annyit kér, hogy a 
legegyszerűbb formátum (esetünkben a sima szöveg) legyen a 
levélben legelöl, majd növekvő bonyolultsági sorrendben követ- 
hetik a további verziók. Így sokkal könnyebb a feldolgozás azok 
számára, akik csak valamely , gyengébb" formátumot ismerik. 


A multipart/related tartalomtípus 

Egymáshoz kapcsolódó üzenetrészek (általában az egyikben 
hivatkozás történik a másikra) azonosítója (RFC 2112). Egy- 
szerűbb megérteni, ha magunk elé képzelünk egy HTML üze- 
netet, ami egy képet tartalmaz (tehát nem csatolt állomány- 
ként, hanem beillesztve). A kép is az üzenetben utazik, a 
HTML kódban pedig speciális hivatkozás szerepel a helyén. 
Ha megnyitunk egy ilyen levelet, a kép az üzenet belsejében 
jelenik meg, és nem érjük el, mint csatolt állományt. Termé- 
szetesen maga a HTML rész sem mint tiszta HTML, hanem 
mint komplex multipart/alternative rész utazik (lásd az előző 
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bekezdést); egy beillesztett képet tartalmazó HTML levélben 
tehát már felismerhetjük az első hierarchikus jellemzőket: 


-lol2d 





B MIME Browser - 6.eml 
File View About... 





mutipatt/relaled . [charset : encoding: 7bit; size: 5435 7 1002) 
8— Ég mutipart/altesmative . charset: : encoding: 7bit; síze: 535 " 107) 
(E) textéplain. (charset iso-8859-2:; encodíng: 7bit: size: 87 " 27) 
€) text/himi. (charset íz0:8859-2: encoding: 7bit: size: 164." 32) 
EH image/peg. (charset : encodíng: base64: size: 4554 " 847) 


0 HTML levél, melyben kép is van 


Egy kérdés nyitott maradt: arról volt szó, hogy a HTML 
tartalom hivatkozik a levélbe ágyazott képre. Pontosan 
hogyan is történik ez? Lássuk a 6.eml forrásának erre vo- 
natkozó részeit (mondjuk a HTML üzenetrészt teljes egészé- 
ben 8) és a kép üzenetrészének elejét 0): 


szett kb 


Content-Transfer-Encoding: 7bit 


--hatarolo szoveg 0001 


Content-Type: text/html 


CxaHTMLOCHEAD2C/HEAD? 
LaBODY2 
SCIMG srcs"cid:content id 0001"2 


Mensa 


£/BODY3c/HTML2 
--hatarolo szoveg 0001-- 


--hatarolo szoveg 0000 


Content-Type: image/jpeg; zést 


namez"MSGIRL2 . jpg" 
Content-Transfer-Encoding: base64 
Content-ID: ccontent id 00015 aes 0) 
/9j/4AROSKZIRgABAOEASABIAAD/ 2wBDAAYEBOYF. . . 
FhYaHSUfGhsjHBYWICwgIyYnKSOPGRStMCOOMCUO . . . 


A határoló szövegeket próbáljuk meg magunk értelmezni, 
de ehhez a teljes kódot látni kell! (Annyit segítek, hogy a 
.0001 végű a multipart/alternative, a 0000 végű pedig a 
multipart/related határolószövege.) A lényeg most az üzenet- 
be ágyazott elemek , címzése". Figyeljük meg, hogy a képet 
tartalmazó üzenetrész tartalmaz egy Content-ID fejlécet O: 


Content-ID: Ccontent id 00015 


A fejléc értéke az adott üzenetrész azonosítója (a kacsa- 
csőrök nem tartoznak az azonosítóhoz). 
A HTML kódban pedig a kép forrásaként nem internetes 
URL (például http://...), hanem egy speciális címzés sze- 
repel (egyébként ez is egyfajta URL) O: 


LIMG srcs"cid:content id 0001"5 


A megjelenítéskor a levelezőprogram a cid: bevezetőből 
tudja, hogy a hivatkozott elemet az üzeneten belül, a 
megadott Content-ID alapján kell megkeresnie. 

A multipart/related tartalomtípusnak van egy kötelező 
type paramétere, ami a ,gyökérként" feldolgozandó üze- 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
LINUX KÜLÖNSZÁM 


44 


4 


a 


45 


SZABVÁNYOK MIME - LEVELEZÉS AZ 
netrész tartalomtípusát tartalmazza (annak az üzenetrész- 
nek, amelyre nem hivatkoznak, hanem ő hivatkozik); ese- 
tünkben ez a multipart/alternative: 


Content-Type: multipart/related; 
type-"multipart/alternative"; 
boundary-"hatarolo szoveg 0000" 


A tartalomtípus többi paramétere opcionális, akit érdekel, 
olvassa el a témáról szóló RFC 2112-t. 


A multipart/signed és multipart/encrypted tartalomtípusok 
Digitálisan aláírt (signed) / titkosított (encrypted) üzene- 
tek (RFC 1847). Kezdjük a végéről: a multipart/encrypted, 
azaz titkosított többrészes üzenet, amely mindig pontosan 
két részből áll. Az első a titkosításhoz szükséges kontroll- 
információ, a második pedig maga a titkosított adatfo- 
lyam, amely application/octet-stream (8 bites adatfolyam) 
tartalomtípust hordoz. A manapság használatos titkosítá- 
sok esetén általában a multipart/encrypted tartalomtípus 
nem szerepel, az S/MIME levelezőprogramok elintézik a 
dolgot egyetlen önhordó (még csak nem is multipart) tit- 
kosított levéllel (amelynek tartalomtípusa nemes egyszerű- 
séggel application/x-pkcs7-mime) . 

Viszont az aláírt levelek! A 7.eml egy egyszerű digitálisan 
aláírt szöveges üzenet. A multipart/signed is mindig pon- 
tosan két üzenetrészt tartalmaz. 











zDl2d 
harset: : encoding: 7bit; size: 4714 " 1007) 
(8) text/plain. (charset is0:8859-2; encodíng: 7bit; size: 107 " 239 
applicationzx-pkos7-signature . (charset: ; encoding: base64; size: 4109 " 87X) 





a Digitálisan aláírt szöveges üzenet 


Ebből az első a digitálisan aláírt, , védett" üzenetrész (bár- 
mi lehet, egyszerű szövegtől az összetett multipart üzenetré- 
szekig); a második pedig az aláírás maga, tartalomtípusa 
az aláírás algoritmusától függ. Ha belenézünk a forráskód- 
jába (most már ideje lenne letölteni azt a MIME Browsert, 
nem?), a fő tartalomtípus fejlécénél ezt látjuk: 


Content-Type: multipart/signed; 
protocol-"application/x-pkcs7-signature" ; 
boundary-"hatarolo-szoveg-0000" ; 


micalg-SHAL 


Jól látható a tartalomtípus három kötelező paramétere. Az 
egyértelmű határolószöveg (boundary) mellett meg kell ad- 
ni a digitális aláírás protokollját (protocol, ez lesz a máso- 
dik üzenetrész tartalomtípusa is), valamint az ellenőrző- 
összeg képzéséhez használt algoritmus (Message Integrity 
Check Algorythm, micalg) nevét. A fejléc tanulsága szerint a 
példában látható digitális aláírás az SHA1 algoritmus segít- 
ségével készült. Ha az első, védett üzenetrészben bármit 
(akár egy üzenetrész-fejlécet is) megváltoztatunk, a digitá- 
lis aláírás azonnal , elromlik" és kiderül a turpisság. 


A multipart/report tartalomtípus 
Bizonyára mindannyian kaptunk már valamelyik levelezőki- 
szolgálótól a levelünk sikertelen vagy akár sikeres kézbesíté- 
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INTERNETEN 


(III. RÉSZ) 

sére vonatkozó válaszlevelet, esetleg visszajelzést arról, hogy 
a címzett elolvasta a levelet. Azt már kevesebben tudják, 
hogy ezeknek a leveleknek speciális formátumuk van, előse- 
gítve ezzel az ilyen üzenetek automatikus feldolgozását. 
Válasszuk ketté a multipart/report (RFC 1892) tartalomti- 
pust! Nézzük meg először, hogyan néz ki egy elolvasást 
visszaigazoló üzenet (read receipt, 8.eml): 


multipart/report . (charset: : encoding: 7bit: size: 1166 7 10072) 
j0-8859-2; encoding: guoted-printable; size: 314 " 277) 





(BODVPART INFORMATION: 
(Content Type: message/disposítion-nolification 
lEncodng: Zbit 

(Charset 














a Read receipt 


A multipart/report első tagja egy egyszerű szöveges üzenet 
arról, hogy elolvastam a magamnak küldött levelet. A máso- 
dik tag pedig egy message/disposition-notification tarta- 
lomtípusú üzenetrész (RFC 2298), aminek tartalma elárulja 
az eredeti üzenet azonosítóját (a levelezőprogramunk tudná 
követni, hogy melyik levélről érkezett visszajelzés!) , hogy vé- 
gülis ki kapta meg az üzenetet (például ha átirányítás tör- 
tént), illetve a visszajelzés elküldésének körülményeit (nem 
automatikusan, hanem az én megkérdezésemmel történt) . 
Lássunk egy kézbesítési üzenetet (Delivery Report) , amely- 
ben a levelezőkiszolgálónk értesít róla, hogy a Télapónak 
egyelőre nem a NetAcademia-hoz kell címezni a leveleket: 


ETTE ES ELEN ETETNEK 


File View About... 


mudipatt/repott. (charset: : encoding: 7: 
(EJ text/olain. (charset: unicode-1-1 


zlOl2d 












ÍBODYPART INFORMATION: z 
(Content Type: message/delívery-status 
7ba 









JDECÖDED CÖNTENT: 
Reporting MTA: dns:mai netacademia net 
fReceived:Ftom-MTA: dasáwiioht 

val Date: Tue, 12.Jun 2001 00.57-56 50200 


Final Recipient: icSZ2telapo(önetacademia net 








0 A Télapó nem nálunk dolgozik... 


Az első rész itt is egy szöveges üzenet a felhasználónak. Az 
üzenetben szerepel még a szóban forgó levél egy-az-egyben 
(message/rfc822, lásd RFC 1521), valamint maga a kézbesí- 
tésről szóló üzenet (message/delivery-status, RFC 1894). 
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SZABVÁNYOK MIME —- 
Most lapozzon vissza a 30. oldalra és tekintse meg még 
egyszer azt a bizonyos HTML levelet, amely beágyazott képet 
és egy csatolt Word dokumentumot tartalmaz, és a végén még 
jól alá is írtuk. Ugye, hogy mégsem annyira bonyolult? 


Egy csendes megjegyzés: a MIME annyira jól ki van ta- 
lálva, hogy az is képes a leveleket olvasni, aki kényte- 
len csupán karakteres (linux/unix) környezetben dol- 
gozni. Még a fenti, igencsak összetett példa is tartal- 
maz tisztán szöveges összetevőt! Mindössze egy rendes, 
MIME-kompatíbilis levelezőprogram kellene hozzá... 


Az MHTML dokumentum 

Egy érdekességet szeretnék mutatni a MIME-ról szóló cikkso- 
rozat végén, aminek érdekes módon a levelezéshez semmi, a 
MIME-hoz viszont annál több köze van. A most leírtakat az 
Internet Explorer 5.0 vagy újabb változatának felhasználói 
már ismerhetik (illetve ha még nem ismernék, akkor kipróbál- 
hatják), aki nem rendelkezik ezzel a verzióval, annak itt az 
ideje frissíteni. Kezdjük az alapproblémával: egy HTML oldal 
tartalmát szeretnénk elmenteni, későbbi olvasgatásra. A 
klasszikus módszer valami ilyesmit eredményez: 









CI www. garfield, com files 
E www garfield. com.htm 


ká a 


I savehtmi 


23KB HTML Document 





Select an item to view its 
description. 


See also: 

Hy Documents 

Mix Network Places 
Hy Computer 


rt 2] 
a Ha egy weblapot elmentünk, a HTML fájl mellett a 
ssallangok" egy külön könyvtárba kerülnek 


Van eset (a Garfield például pont ilyen :-) ), hogy nem 
gond, sőt előny, ha egy weblapon található képek, grafi- 
kák külön-külön a lemezre íródnak. Máskor azonban kifeje- 
zetten macera a fájl és a hozzá tartozó könyvtár együttes 
másolgatása (próbáljuk ki, és hozzunk létre egy könyvtárat 
és egy HTML fájlt, mint a fenti példában; azután töröljük ki 
a HTML fájlt, és csodák csodájára a Windows a megkérdezé- 
sünk nélkül törli a (szerinte) hozzá tartozó könyvtárat is .. 
khm..). Egyszóval ezzel sokszor csak a baj van. 

Nem lehetne összecsapni az egészet egyetlen fájlba? (Na 
jó, nem a tömörítésre gondolok. ..). Dehogynem. Az Inter- 
net Explorer 5.0-tól kezdve a Save As... ablakban egy ed- 
dig ismeretlen, új formátumot is kiválaszhatunk: 

1 


File name: 


Official Site For Garfield And Friends 7 


EE 


Save as lype: 





5 IE5-től kezdve Garfield-ot .mht-ba is menthetjük 
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LEVELEZÉS AZ INTERNETEN (III. RÉSZ) 
Web Archive, single file" (webarchívum, egyetlen fájl) - 
mondja a magyarázat az .mht kiterjesztés mellett. Nosza, 
próbáljuk ki! A mentés végén valóban egy fájl keletkezik 
(néhányat a [2] címről is letölthet a lelkes Olvasó). Hurrá! 


Semmi sallang! 


Na de mi köze ennek a MIME-hoz?! 

Rögtön meglátjuk, ha egy .mht fájlt a jó öreg MIME Brow- 
ser-be vontatunk (persze akkor is kiderül a turpisság, ha 
egyszerűen megnyitjuk, mondjuk NotePad-del). Az .mht 
fájl (MHTML dokumentum) nem más, mint egy MIME for- 
mátumú HTML , levél", beágyazott objektumokkal. 


4 garfield.mht - Notepad üz 

File Edit Format Help 

From: csaved by Microsoft Internet Explorer 55 
Subject: Official Site For Garfield And Friends 
ate: Mon, 18 Jun 2001 23:12:38 40200 





lDl2 





IME-Version: 1.0 

ontent-Type: multipart/rela ated; 
undaryz"--—-z, -NextPart. 000. 0000. O1COF84C. 2AEJASAO" 

typez"text/htmi" 

-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 

This is a multi-part message ín MIME format. 

ennatti -NextPart, 000. 0000. O1COF84C , 2AE3A9AD 

ontent-Type: text/html; 

charset:"windows-1250" 

ontent-Transfer-Encoding: guoted-printable 





5 Az. .mht fálj valójában egy HTML levél, az M betű a 
MIME-ot jelképezi: MHTML Document 


Még feladója, feladási dátuma és témája is van! És hogy 
mi van belül? Rögtön meglátjuk, ha megnyitunk egy ilyen 
fájlt a MIME Browserrel: 





EKKTEZETETET BE DIX 


File View About... 





mudlipat/relaled . feharset : encoding: 7bal; size: 140382 7 10077 
text/html (charset windows:1250: encoding: guoted pintable; size: 23897 172) 
[9] image/gi  (charset : encodng: base64; síze: 10450." 73) 
[ed] image/gi  (charset : encoding: base64; size: 321 7 07) 
fed image/gi. leharset ; encodng: baseS4; size: 282. 079 


b 





Mög sgvsednvslerastt  fotramat: Zenoodíya egett páráatáas eles 27528 - 199 
Én appócation/xjavasciipt (charset : encoding: gyoted-printable; size: 11477 129 
Pie: 7.75 köyte4 869 bytes) 
parts: 0 





beli 





JDECODED CONTENT? 
ISTYLE typetextcss .standard ( 

FONT-SIZE: x-small; COLOR: black; FONT-FAMILY: Arial, Verdana, Geneva, Helvetica, sans-serif 
p 


I input ( 
FONT-SIZE: xx-small; COLOR: £000000; FONT-FAMILY: Verdöna, Geneva, Arial, Helvetica, sans- 


4 





8odypan information 


a A Microsoft Magyarország elmentett weblapja a MI- 
ME Browserben 


Az ábrán a Microsoft Magyarország .mht-ba mentett főlapjá- 
nak kicsit kozmetikázott képe látható (az itt láthatónál sok- 
kal több kép van a fájlban, de ez ne zavarjon meg senkit). Az 
üzenet típusa értelemszerűen multipart/related (aki nem érti 
miért pont ez, lapozzon vissza); az első elem természetesen 
maga a HTML kód, majd azt követik szépen a hozzá kapcso- 
lódó üzenetrészek: képek, stíluslapok, javascript-darabkák. 


Fülöp Miklós 
mick Onetacademia.net 
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